Концептуальная модель

Материал из Википедии — свободной энциклопедии

В другом языковом разделе есть более полная статья Model (wetenschap) (нид.) Вы можете помочь проекту, дописав эту статью с помощью перевода.

Эта статья или раздел нуждается в переработке. Пожалуйста, улучшите её в соответствии с правилами написания статей.

Концептуа́льная моде́ль (англ. conceptual model) — это определённое множество понятий и связей между ними, являющихся смысловой структурой рассматриваемой предметной области.

Концептуальная модель — модель предметной области, состоящей из перечня взаимосвязанных понятий, используемых для описания этой области, вместе со свойствами и характеристиками, классификацией этих понятий, по типам, ситуациям, признакам в данной области и законов протекания процессов в ней. (Толковый словарь по искусственному интеллекту)

Концептуальная (содержательная) модель — это абстрактная модель, определяющая структуру моделируемой системы, свойства её элементов и причинно-следственные связи, присущие системе и существенные для достижения цели моделирования.

Концептуальная модель: первый важный шаг в проектировании пользовательского интерфейса Джефф Джонсон (Jeff Johnson), UI Wizards, Inc.

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

Определение

В двух словах, концептуальная модель приложения — это модель, которую проектировщик хочет довести до понимания пользователя. Используя приложение и читая документацию к нему, пользователь выстраивает в голове модель функционирования системы. Хорошо, если модель, возникшая в голове пользователя, и модель, задуманная проектировщиком, совпадают. Шансы на это выше, если проектировщик предварительно создаст четкую концептуальную модель.

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

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

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

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

Пример

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

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

Преимущества

Разработка концептуальной модели как первая стадия проектирования пользовательского интерфейса имеет ряд преимуществ:

Разделение области задач на объекты и действия позволяет определить действия, одинаковые для нескольких объектов. Впоследствии один и тот же пользовательский интерфейс может быть использован для работы с разными объектами. Например, если в хорошо продуманном приложении пользователь может использовать объекты А и Б, и он хочет создать объект А, но умеет создавать только Б, он сумеет создать и А, поскольку это действие происходит единообразно для двух данных объектов. Как впрочем и копирование, перемещение, удаление, редактирование, печать и т.д. Это в свою очередь делает пользовательский интерфейс более простым и последовательным, а значит и более удобным в изучении и использовании. Даже если не брать в расчёт упрощение, вызванное существованием обобщенных действий, при проектировании пользовательской модели разработчики должны признать относительную важность концептов, значимость концептов для области задач (в противоположность технической области), типовую иерархию и иерархию включения объектов. Все эти явления в значительной степени облегчают проектирование пользовательского интерфейса. Концептуальная модель представляет собой начальный этап разработки терминологии программного продукта, то есть словаря терминов, которые будут использоваться для идентификации каждого объекта и действия, реализованного в программе. Это способствует сохранению устойчивости терминологии не только в самой программе, но и в сопутствующей документации. Недостатками программы, разработанной без такой терминологии, являются: 1) использование многочисленных терминов для определения одного концепта; 2) использование одного термина для определения разных концептов. Наконец разработка концептуальной модели представляет собой первоначальный вид объектной модели (по крайней мере, для объектов, необходимых пользователю), которую разработчики могут в дальнейшем использовать при реализации программного обеспечения. Это особенно актуально если разработчик пишет программу на объектно-ориентированных языках, таких как Java или С++. Риск отказа от использования концептуальной модели

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

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

Для регистрации количества рабочих часов за неделю сотрудник нажимает «Создать запись» вместо того, чтобы нажать «Зарегистрировать часы» или «Зарегистрировать новую неделю». Почему именно «Создать запись»? Поскольку для сохранения новой информации в базе данных надо сделать в ней новую запись. Если пользователю удается зарегистрировать количество рабочих часов в неделю, система генерирует сообщение «Операция прошла успешно: новая строка добавлена». Что? Это сообщение не только не имеет никакого отношения к регистрируемым часам, но даже и не относится к функциональному термину программы «Создать запись». Если сотрудник вдруг забудет, что он уже регистрировал свои рабочие часы за определённую неделю и попытается сделать это ещё раз, система выдаст сообщение об ошибке «ORA-00001: ограничение (CLEATS. PA_REPORT_HEADERS_U!) нарушено», информирующее пользователя, что какое-то внутреннее программное ограничение было им нарушено. И это вместо понятной записи «Регистрация часов за эту неделю уже была внесена». Функция изменения пароля предполагает введение любой последовательности букв в качестве нового пароля, а буквенный логин наоборот неприемлем. Таким образом, паролем может служить комбинация, которую функция Логин сочтет ошибочной.