Локус внимания — это некоторое место или область, на которое может быть сосредоточено ваше внимание. В отличие от фокуса, часто обозначающего не только место, но и действие (сфокусировать ваше внимание), локус обозначает только место и переводится с латинского, как место положения или область.
В каждый момент времени фокус внимания может фиксироваться в одной точке. Поэтому, если возникает необходимость «одновременно» отслеживать несколько ситуаций, то обычно фокус перемещается с одного отслеживаемого элемента на другой. При этом внимание «рассредоточивается», и какие-то детали могут быть упущены.
Обработка процессором восприятия требует некоторого времени и, если сигнал выдается в течение времени, меньшем времени обработки, то наш мозг его не воспринимает.
Восприятие во многом основано на мотивации. Например, если человек голоден, то он в первую очередь будет замечать все съедобное, а если устал – то, войдя в комнату, он в первую очередь увидит диван или кровать.
В процессе переработки информации мозг сравнивает поступающие данные с предыдущими.
При смене кадра мозг на некоторое время блокируется: он «осваивает» новую картинку, выделяя наиболее существенные детали. А значит, если необходима быстрая реакция пользователя, то резко менять картину не стоит.
Диаграммы последовательностей - это отличное средство документирования поведения системы, детализации логики сценариев использования; но есть еще один способ - использовать диаграммы взаимодействия. Диаграмма взаимодействия показывает поток сообщений между объектами системы и основные ассоциации между ними и по сути, как уже было сказано выше, является альтернативой диаграммы последовательностей. Внимательный читатель, возможно, скажет, что диаграмма объектов делает то же самое, - и будет не прав. Диаграмма объектов показывает статику, некий снимок системы, связи между объектами в данный момент времени, диаграмма же взаимодействия, как и диаграмма последовательностей, показывает взаимодействие (извините за невольный каламбур) объектов во времени, т. е. в динамике.
Следует отметить, что использование диаграммы последовательностей или диаграммы взаимодействия - личный выбор каждого проектировщика и зависит от индивидуального стиля проектирования. Мы, например, чаще отдаем предпочтение диаграмме последовательностей. На обозначениях, применяемых на диаграмме взаимодействия, думаем, не стоит останавливаться подробно. Здесь все стандартно: объекты обозначаются прямоугольниками с подчеркнутыми именами (чтобы отличить их от классов, помните?), ассоциации между объектами указываются в виде соединяющих их линий, над ними может быть изображена стрелка с указанием названия сообщения и его порядкового номера.
Необходимость номера сообщения объясняется очень просто - в отличие от диаграммы последовательностей, время на диаграмме взаимодействия не показывается в виде отдельного измерения. Поэтому последовательность передачи сообщений можно указать только с помощью их нумерации. В этом и состоит вероятная причина пренебрежения этим видом диаграмм многими проектировщиками.
Диаграмма классов (англ. StaticStructurediagram) — диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи между ними. Входит в UML.
Существует два вида:
· Статический вид диаграммы рассматривает логические взаимосвязи классов между собой;
· Аналитический вид диаграммы рассматривает общий вид и взаимосвязи классов, входящих в систему.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
· Концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
· Точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
· Точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Диаграмма классов является ключевым элементом в объектно-ориентированном моделировании. На диаграмме классы представлены в рамках, содержащих три компонента:
· В верхней части написано имя класса. Имя класса выравнивается по центру и пишется полужирным шрифтом. Имена классов начинаются с заглавной буквы. Если класс абстрактный — то его имя пишется полужирным курсивом.
· Посередине располагаются поля (атрибуты) класса. Они выровнены по левому краю и начинаются с маленькой буквы.
· Нижняя часть содержит методы класса. Они также выровнены по левому краю и пишутся с маленькой буквы.
По мере повторения – или с практикой – выполнение того или иного действия становится для вас привычным, и вы можете выполнять его не задумываясь. Печатать на машинке слепым методом, так же, как и ездить на велосипеде или ходить пешком по тропинке, лучше всего получается, если об этом не задумываться.
Когда вы выполняете какую-то задачу многократно, то с каждым разом делать это становится всё проще.
По мере повторения – или с практикой – выполнение того или иного действия становится для вас привычным, и вы можете выполнять его не задумываясь.
При постоянном использовании какого-либо интерфейса у вас формируются определенные привычки, которые впоследствии трудно преодолеть. В этом смысле задача дизайнеров заключается в том, чтобы создавать интерфейсы, которые не позволяют привычкам вызывать проблемы у пользователей.
Перцептивные действия — структурные единицы процесса восприятия у человека. Перцептивные действия обеспечивают сознательное выделение того или иного аспекта чувственно заданной ситуации, а также преобразование сенсорной информации, приводящее к построению образа, адекватного предметному миру и задачам деятельности.
Большинство восприятий утрачиваются после того, как затухают.
С точки зрения разработки интерфейсов из быстрого затухания сенсорных восприятий следует, что человек, прочитавший или услышавший 5 секунд назад некоторое сообщение, необязательно сможет вспомнить его содержание.
Если такое сообщение важно само по себе или содержит важную деталь, то оно должно оставаться на экране до тех пор, пока не перестанет быть актуальным.
Гибкость интерфейса — это способность самонастраивания интерфейса, который учитывает уровень подготовки и производительность труда пользователя.
Полностью гибких интерфейсов не существует, но элементы гибкости должны присутствовать.
Концепция гибкого интерфейса в настоящее время является одной из основных областей исследования взаимодействия человека и ЭВМ.
Основная проблема состоит не в том, как организовать изменения в диалоге, а в том, какие признаки нужно использовать для определения необходимости внесения изменения и их сути.
Естественный интерфейс - интерфейс, который не вынуждает пользователя существенно изменять привычные для него способы решения задачи. Это, в частности, означает, что сообщения и результаты, выдаваемые приложением, не должны требовать дополнительных пояснений. Целесообразно также сохранить систему обозначений и терминологию, используемые в данной предметной области.
Использование знакомых пользователю понятий и образов (метафор) обеспечивает интуитивно понятный интерфейс при выполнении его заданий. Вместе с тем, использование метафоры не должно ограничивать их машинную реализацию полной аналогией с одноименными объектами реального мира. Например, в отличие от своего бумажного аналога, папка на Рабочем столе Windows может использоваться для хранения разных объектов (таких, например, как принтеры, калькуляторы, другие папки). Метафоры являются своего рода "мостиком", связывающим образы реального мира с теми действиями и объектами, которыми приходится манипулировать пользователю при его работе на компьютере; они обеспечивают "узнавание", а не "вспоминание". Пользователи запоминают действие, связанное со знакомым объектом, более легко, чем они запомнили бы имя команды, связанной с этим действием.
UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
В UML используются следующие виды диаграмм:
Структурные диаграммы:
Диаграмма классов
Диаграмма компонентов
Диаграмма композитной/составной структуры
Диаграмма кооперации (UML2.0)
Диаграмма развёртывания
Диаграмма объектов
Диаграмма пакетов
Диаграмма профилей (UML2.2)
Диаграммы поведения:
Диаграмма деятельности
Диаграмма состояний
Диаграмма вариантов использования
Диаграммы взаимодействия:
Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
Диаграмма обзора взаимодействия (UML2.0)
Диаграмма последовательности
Диаграмма синхронизации (UML2.0)
Согласованность позволяет пользователям переносить имеющиеся знания на новые задания, осваивать новые аспекты быстрее и благодаря этому фокусировать внимание на решаемой задаче, а не тратить время на уяснение различий в использовании тех или иных элементов управления, команд и т.д. Обеспечивая преемственность полученных ранее знаний и навыков, согласованность делает интерфейс узнаваемым и предсказуемым.
Согласованность важна для всех аспектов интерфейса, включая имена команд, визуальное представление информации и поведение интерактивных элементов. Для реализации свойства согласованности в создаваемом программном обеспечении необходимо учитывать его различные аспекты.
1. Согласованность в пределах продукта. Одна и та же команда должна выполнять одни и те же функции, где бы она ни встретилась, причем одним и тем же образом. Например, если в одном диалоговом окне команда копировать означает немедленное выполнения соответствующих действий, то в другом окне она не должна требовать от пользователя дополнительно указать расположение копируемой информации. Другими словами, нужно использовать одну и туже команду, чтобы выполнить функции, которые кажутся подобными пользователю.
2. Согласованность в пределах рабочей среды. Поддерживая согласованность с интерфейсом, предоставляемым операционной системой (например, ОС Windows), приложение может "опираться" на те знания и навыки пользователя, которые он получил ранее при работе с другими приложениями.
3. Согласованность в использовании метафор. Если поведение некоторого программного объекта выходит за рамки того, что обычно подразумевается под соответствующей ему метафорой, у пользователя могут возникнуть трудности при работе с таким объектом. Например, если для программного объекта Корзина определить операцию Запуск, то для уяснения ее смысла пользователю, скорее всего, потребуется посторонняя помощь.
Диаграмма прецедентов (диаграмма вариантов использования) в UML — диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне[1].
Прецедент — возможность моделируемой системы (часть её функциональности), благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат. Прецедент соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе
Основное назначение диаграммы — описание функциональности и поведения, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать проектируемую или существующую систему.
При моделировании системы с помощью диаграммы прецедентов системный аналитик стремится:
чётко отделить систему от её окружения;
определить действующих лиц (актёров), их взаимодействие с системой и ожидаемую функциональность системы;
определить в глоссарии предметной области понятия, относящиеся к детальному описанию функциональности системы (то есть, прецедентов).
Работа над диаграммой может начаться с текстового описания, полученного при работе с заказчиком. При этом нефункциональные требования (например, конкретный язык или система программирования) при составлении модели прецедентов опускаются (для них составляется другой документ)
Для отражения модели прецедентов на диаграмме используются:
рамки системы (англ. system boundary) — прямоугольник с названием в верхней части и эллипсами (прецедентами) внутри. Часто может быть опущен без потери полезной информации,
актёр (англ. actor) — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Актёры не могут быть связаны друг с другом (за исключением отношений обобщения/наследования),
прецедент — эллипс с надписью, обозначающий выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. Надпись может быть именем или описанием (с точки зрения актёров) того, «что» делает система (а не «как»). Имя прецедента связано с непрерываемым (атомарным) сценарием — конкретной последовательностью действий, иллюстрирующей поведение[2]. В ходе сценария актёры обмениваются с системой сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев.
Отношения между прецедентами
Часть дублирующейся информации в модели прецедентов можно устранить указанием связей между прецедентами:
обобщение прецедента — стрелка с незакрашенным треугольником (треугольник ставится у более общего прецедента),
включение прецедента — пунктирная стрелка со стереотипом «include»,
расширение прецедента — пунктирная стрелка со стереотипом «extend» (стрелка входит в расширяемый прецедент, в дополнительном разделе которого может быть указана точка расширения и, возможно в виде комментария, условие расширения).
При работе с вариантами использования важно помнить несколько простых правил:
каждый прецедент относится как минимум к одному действующему лицу;
каждый прецедент имеет инициатора;
каждый прецедент приводит к соответствующему результату.