Файл: Лекции на специальности спо базовой подготовки 09. 02. 07 Информационные системы и программирование Ульяновск.docx

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 06.05.2024

Просмотров: 93

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
, а также содержит рекомендации для разработчиков по реализации модулей. На сегодня Python поддерживает через модули расширения многие известные базы данных.

Доступ к базе данных осуществляется с помощью объекта-соединения (connection object). DB-API-совместимый модуль должен предоставлять функцию-конструктор connect() для класса объектов-соединений. Конструктор должен иметь следующие именованные параметры:

  • dsn Название источника данных в виде строки

  • user Имя пользователя

  • password Пароль

  • host Адрес хоста, на котором работает СУБД

  • database Имя базы данных.

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

  • apilevel Версия DB-API ("1.0" или "2.0").

  • threadsafety Целочисленная константа, описывающая возможности модуля при использовании потоков управления:

  • 0 Модуль не поддерживает потоки.

  • 1 Потоки могут совместно использовать модуль, но не соединения.

  • 2 Потоки могут совместно использовать модуль и соединения.

  • 3 Потоки могут совместно использовать модуль, соединения и курсоры. (Под совместным использованием здесь понимается возможность использования упомянутых ресурсов без применения семафоров).

  • paramstyle Тип используемых пометок при подстановке параметров. Возможны следующие значения этой константы:

  • "format" Форматирование в стиле языка ANSI C (например, "%s", "%i" ).

  • "pyformat" Использование именованных спецификаторов формата в стиле Python ( "%(item)s" )

  • "qmark" Использование знаков "?" для пометки мест подстановки параметров.

  • "numeric" Использование номеров позиций ( ":1" ).

  • "named" Использование имен подставляемых параметров ( ":name" ).

Модуль должен определять ряд исключений для обозначения типичных исключительных ситуаций: Warning (предупреждение), Error (ошибка), InterfaceError (ошибка интерфейса), DatabaseError (ошибка, относящаяся к базе данных). А также подклассы этого последнего исключения: DataError (ошибка обработки данных), OperationalError (ошибка в работе или сбой соединения с базой данных), IntegrityError (ошибка целостности базы данных), InternalError (внутренняя ошибка базы данных), ProgrammingError (программная ошибка, например, ошибка в синтаксисе SQL-запроса), NotSupportedError (при отсутствии поддержки запрошенного свойства).
Объектно-реляционное отображение (ORM)

ORM или Object-relational mapping (рус. Объектно-реляционное отображение) — это технология программирования, которая позволяет преобразовывать несовместимые типы моделей в ООП, в частности, между хранилищем данных и объектами программирования. ORM используется для упрощения процесса сохранения объектов в реляционную базу данных и их извлечения, при этом ORM сама заботится о преобразовании данных между двумя несовместимыми состояниями. Большинство ORM-инструментов в значительной мере полагаются на метаданные базы данных и объектов, так что объектам ничего не нужно знать о структуре базы данных, а базе данных — ничего о том, как данные организованы в приложении. ORM обеспечивает полное разделение задач в хорошо спроектированных приложениях, при котором и база данных, и приложение могут работать с данными каждый в своей исходной форме.


Использование ORM решает проблему так называемой парадигмы «несоответствия», которая гласит о том, что объектные и реляционные модели не очень хорошо работают вместе. Реляционные базы представляют данные в табличном формате, в то время как объектно-ориентированные языки представляют их как связанный граф объектов.

Основные проблемы и несоответствия возникают во время сохранения этого графа объектов в реляционную базу или его загрузки:

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

  • реляционные СУБД не имеют ничего похожего на наследование — естественную парадигму объектно-ориентированных языков программирования;

  • в СУБД определен только один параметр для сравнения записей — первичный ключ. В то время как ООП предоставляет как проверку идентичности объектов (a==b), так и их равенства (a.equals(b));

  • для связи объектов СУБД использует понятие внешних ключей, в объектно-ориентированных языках связь между объектами может быть только однонаправленной. Если же нужно организовать двунаправленные отношения, то придется определить две однонаправленные ассоциации.

Ключевой особенностью ORM является отображение, которое используется для привязки объекта к его данным в БД. ORM как бы создает «виртуальную» схему базы данных в памяти и позволяет манипулировать данными уже на уровне объектов. Отображение показывает, как объект и его свойства связанны с одной или несколькими таблицами и их полями в базе данных. ORM использует информацию этого отображения для управления процессом преобразования данных между базой и формами объектов, а также для создания SQL-запросов для вставки, обновления и удаления данных в ответ на изменения, которые приложение вносит в эти объекты.
Тема 7 Разработка пользовательского интерфейса

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

Правило 1: дать контроль пользователю

Принципы, которые дают пользователю контроль над системой:

1)использовать режимы благоразумно;

2)предоставить пользователю возможность выбирать: работать либо мышью, либо клавиатурой, либо их комбинацией;


3)позволить пользователю сфокусировать внимание;

4)демонстрировать сообщения, которые помогут ему в работе;

5)создать условия для немедленных и обратимых действий, а также обратной связи;

6)обеспечить соответствующие пути и выходы;

7)приспосабливайте систему к пользователям с различным уровнем подготовки;

8)сделать пользовательский интерфейс более понятным;

9)дать пользователю возможность настраивать интерфейс по своему вкусу;

10)разрешить пользователю напрямую манипулировать объектами интерфейса;

Правило 2: уменьшить нагрузку на пользователя

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

Принципы, позволяющие снизить нагрузку на память пользователя:

1)не загружать кратковременную память;

2)полагаться на распознавание, а не на повторение;

3)представить визуальные заставки;

4)предусмотреть установки по умолчанию, команды Undo и Rendo;

5)предусмотреть "быстрые" пути;

6)активировать синтаксис действий с объектами;

7)использовать метафоры из реального мира;

8)применять раскрытие и объяснение понятий и действий;

9)увеличить визуальную ясность.

Правило 3: сделать интерфейс совместимым

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

Принципы создания совместимости интерфейса:

1)проектирование последовательного интерфейса;

2)общая совместимость всех программ;

3)сохранение результатов взаимодействия;

4)эстетическая привлекательность и цельность;

5)поощрение изучения;
Требования к интерфейсу

Основные требования к пользовательскому интерфейсу:

  • функциональность (соответствие задачам пользователя);

  • соответствие технологии;

  • понятность и логичность;

  • обеспечение высокой скорости работы пользователя;

  • обеспечение защиты от человеческих ошибок;

  • быстрое обучение пользователя;

  • субъективное удовлетворение пользователя.

На основе общих требований к пользовательскому интерфейсу сформирована система требований к его элементам управления.


  • Требования к названию (тексту) элементов управления:

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

  • Требования к расположению элементов управления:

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

  • Требования к оформлению чекбоксов и радиокнопок:

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

Анализ интерфейса

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

Какие параметры нужно оценить

1. Изменения контекста: движение пользователя внутри продукта для завершения шага. Пример: незначительное изменение контекста при переносе пользователя на новую страницу

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

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

4. Обратная связь системы: реакция системы на действия пользователя во время выполнения шага. Пример: журнал уведомлений в режиме реального времени отражает шаги, предпринятые пользователем

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

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

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

Основные возможные проблемы:

  • Непонятные элементы и сложная процедура решения базовых задач пользователя

  • Плохо работает поиск и фильтрация товаров

  • Непонятное описание характеристик и некорректное изображение товара

  • Фотографии товара не дают представления о внешнем виде товара.

  • Непонятные условия акций, спецпредложений, товаров в подарок

  • Непонятные формулировки и условия акций.

  • Неправильный подбор сопутствующих товаров и неудобное для пользователя размещение на сайте

  • Сопутствующие товары размещены перед характеристиками, и пользователь их проматывает, не посмотрев.