Файл: Варианты построения интерфейса программ: особенности и эволюция (Сущность интерфейсов).pdf

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

Категория: Курсовая работа

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

Добавлен: 30.03.2023

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

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

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

ВВЕДЕНИЕ

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

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

Цель данной работы – рассмотрение процесса построения интерфейсных программ.

Для достижения поставленной цели в ходе работы, будут решены следующие задачи:

1.Рассмотрено, что представляет из себя «Интерфейс».

2. Рассмотрены принципы построения интерфейсных программ.

Структура работы состоит из введения, основной части, заключения и списка литературы.

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПОСТРОЕНИЯ ИНТЕРФЕЙСНЫХ ПРОГРАММ

1.1 Сущность интерфейсов

Интерфейс — программная/синтаксическая структура, определяющая отношение между объектами, которые разделяют определенное поведенческое множество и не связаны никак иначе. При проектировании классов, разработка интерфейса тождественна разработке спецификации (множества методов, который каждый класс, использующий интерфейс должен реализовывать).

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

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

Описание ООП-интерфейса, если отвлечься от деталей синтаксиса конкретных языков, состоит из двух частей: имени и методов интерфейса.


  • Имя интерфейса строится по тем же правилам, что и другие идентификаторы используемого языка программирования. Разные языки и среды разработки имеют различные соглашения по оформлению кода, в соответствии с которыми имена интерфейсов могут формироваться по некоторым правилам, которые помогают отличать имя интерфейса от имён других элементов программы. Например, в технологии COM и во всех поддерживающих её языках действует соглашение, следуя которому, имя интерфейса строится по шаблону «I<Имя>», то есть состоит из написанного с заглавной буквы осмысленного имени, которому предшествует прописная латинская буква I (IUnknown, IDispatch, IStringList и т. п.).
  • Методы интерфейса. В описании интерфейса определяются имена и сигнатуры входящих в него методов, то есть процедур или функций класса.

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

  • Класс может реализовывать интерфейс. Реализация интерфейса заключается в том, что в описании класса данный интерфейс указывается как реализуемый, а в коде класса обязательно определяются все методы, которые описаны в интерфейсе, в полном соответствии с сигнатурами из описания этого интерфейса. То есть, если класс реализует интерфейс, для любого экземпляра этого класса существуют и могут быть вызваны все описанные в интерфейсе методы. Один класс может реализовать несколько интерфейсов одновременно.
  • Возможно объявление переменных и параметров методов как имеющих тип «интерфейс». В такую переменную или параметр может быть записан экземпляр любого класса, реализующего интерфейс. Если интерфейс объявлен как тип возвращаемого значения функции, это означает, что функция возвращает объект класса, реализующего данный интерфейс.

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

Таким образом, с одной стороны, интерфейс — это «договор», который обязуется выполнить класс, реализующий его, с другой стороны, интерфейс — это тип данных, потому что его описание достаточно чётко определяет свойства объектов, чтобы наравне с классом типизировать переменные. Следует, однако, подчеркнуть, что интерфейс не является полноценным типом данных, так как он задаёт только внешнее поведение объектов. Внутреннюю структуру и реализацию заданного интерфейсом поведения обеспечивает класс, реализующий интерфейс; именно поэтому «экземпляров интерфейса» в чистом виде не бывает, и любая переменная типа «интерфейс» содержит экземпляры конкретных классов.


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

Например, интерфейс «Cloneable» может описать абстракцию клонирования (создания точных копий) объектов, специфицировав метод «Clone», который должен выполнять копирование содержимого объекта в другой объект того же типа. Тогда любой класс, объекты которого может понадобиться копировать, должен реализовать интерфейс Cloneable и предоставить метод Clone, а в любом месте программы, где требуется клонирование объектов, для этой цели у объекта вызывается метод Clone. Причём, использующему этот метод коду достаточно иметь только описание интерфейса, он может ничего не знать о фактическом классе, объекты которого копируются.

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

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

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

Например[1]:

Рисунок 1 – Примеры интерфейс программ

Когда проектируешь новый интерфейс, нужно учитывать не только интересы заказчика, у которого в основном одна цель — обеспечить финансовый поток, но и мотивацию пользователей. Когда ты понимаешь, что твой пользователь — не абстрактный бухгалтер, а женщина 60-ти лет, которая хочет пораньше уйти c работы и не учить ничего нового, это сильно влияет на интерфейс. Ты учитываешь, что она не захочет делать, и как её можно заставить — кнутом или пряником — всё-таки сделать то, что необходимо.


Для этого подойдут игровые механики. Допустим, надо подготовить квартальный отчёт. Мы можем использовать кнут: установить напоминалку о том, что осталось всего два дня до дедлайна, и штрафовать за опоздания. А можно использовать пряник: сделать так, что, удовлетворяя свои собственные потребности, сотрудник автоматически выполнит бизнес-задачу. Условно говоря, чтобы накормить своего тамагочи, он должен будет отправить квартальный отчёт. У нас был такой проект: несколько отделов логистики компании соревновались друг с другом в числе обработанных заказов, а в конце месяца победитель получал бонус. Но в течение месяца никто не знал, кто впереди. Когда мы вытащили соревнование в интерфейс так, что сотрудник в реальном времени видел, что от его заказа зависит судьба бонуса всего отдела, производительность труда заметно повысилась.

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

Отличный пример из прошлого: известно, что танки Т-34 были неудобными. Когда стали решать, стоит ли в них что-то менять, то поняли, что делать это бессмысленно. Среднее время участия танка в бою — 11 минут, и за это время танкисты не успевают устать. В остальное время экипаж  редко находится внутри танка: он едет на броне. Задача сделать всё максимально удобным стоит не всегда. 

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

Но уже сейчас игровая индустрия активно внедряет новые технологии измерения реакций пользователей. Там уже строят интерфейсы на основе оценки психофизиологического состояния игрока. Если система понимает, что ты нервничаешь, твой прицел в стрелялке становится больше. В Mail.ru есть лаборатория, где отслеживают различные параметры игрока: частоту пульса, дыхания, кожно-гальваническое сопротивление и другое. Пока это делают специальные аппаратно-программные комплексы. Но думаю, в скором времени такие измерения могут стать доступными при помощи веб-камеры, которая будет замерять частоту пульса по зрачкам. Этот тренд распространится и за пределы индустрии игр. Система будет знать многое о вашем состоянии и на основе этого взаимодействовать с вами. Например, если станет ясно, что вы сосредоточены на работе и вас лучше не беспокоить, она не будет показывать вам уведомления о письмах со стандартным и низким приоритетом.


Одно из главных правил хорошего интерфейса: нужно ориентироваться на ментальную модель пользователя, а не на реальную структуру системы. Ментальная модель — это то, как он представляет себе систему. Чаще всего он воспринимает её упрощённо. Например, когда мы говорим по телефону, мы представляем, как радиоволны бегут от одного к другому. В реальности всё сложнее, но для разговора нам знать об этом не нужно. Люди ожидают от системы определённого поведения, и на это стоит ориентироваться.   

Важно делать интерфейс для реальных людей. Часто заказчики делают продукт под самих себя. Мы тестировали интерфейс одного клиент-банка и заметили, что 80% пользователей не могли выполнить задачу «отправить документ бенефициару», потому что не знали слова «бенефициар». Когда мы рассказали об этом заказчикам, они ответили, что только идиоты не знают этого слова. То есть они не могли представить, что их пользователи могут быть абсолютно не похожи на них.

Tcnm концепция MetroUI, которая уловила важный тренд: люди перестали бояться быть цифровыми. Раньше многим интерфейсам была свойственна метафоричность. Мы с помощью объектов на экране изображали объекты из реальной жизни — только так можно было дать представление об их функциях. Люди видели кнопку и понимали, что на неё можно нажать, видели корзинку и понимали, что в неё можно выбросить ненужные документы. Сейчас настал момент, когда можно отказаться от искусственной связи с реальным миром и делать чисто цифровые интерфейсы.  Дети знакомятся с компьютером раньше, чем с корзиной для бумаг.

 Проектировать нужно не интерфейс, а сервис, где продукт является лишь одной из точек контакта с пользователем. Это может быть и реклама на радио, и офис, и сайт. Все они имеют смысл, если помогают пользователю решить его проблему, удовлетворить потребность. Сам по себе интерфейс никому не нужен, потому что он самостоятельно не решает никакую задачу. Так же, как и продукт. Сайт банка без банка — бред. Я заполняю анкету на сайте, и мне предлагают после этого прийти в отделение — это вроде бы нормально и современно. Но на деле даже этот момент — точка разрыва сервиса с пользователем. Чтобы не оставлять его предоставленным самому себе, можно предложить выбрать ближайшее к нему отделение, назначить удобное время визита или напомнить о документах, которые нужно принести. Не говоря уж о постоянном ведении клиента с использованием смартфона.

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