АНАЛИТИЧЕСКИЕ МОДЕЛИ КАРТЫ Российский патент 2013 года по МПК G06F19/00 

Уровень техники

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

В самое последнее время эти визуальные элементы создаются электронным образом, например с использованием приложений систем автоматизированного проектирования (САПР, CAD) или монолитного моделирования. Зачастую эти приложения предоставляют авторам возможность привязывать данные и ограничения к геометрии. Например, приложение для составления спецификации материалов могло предусматривать атрибуты, такие как номер и поставщик детали, которые должны быть ассоциированы с каждой деталью, максимальный угол между двумя компонентами, или тому подобное. Приложение, которое строит электронный вариант стадиона, могло иметь инструментальное средство для задания минимального промежутка между сиденьями, и так далее.

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

Сущность изобретения

Варианты осуществления, описанные в материалах настоящей заявки, относятся к построению вида карты, который содержит в себе многочисленные визуальные элементы карты. Каждый из визуальных элементов карты может быть сконструирован и размещен на месте с использованием логики, определенной компонентом вида карты, соответствующим каждому визуальному элементу карты, где такая логика может зависеть от одного или более значений, заполненных в параметр(ы) компонента вида карты. Некоторые из этих значений параметров могут соответствовать известным значениям параметров модели. Другие, однако, могли быть вычислены с использованием модели, которая определяет аналитические соотношения между параметрами модели карты. В одном из вариантов осуществления, какие параметры модели карты известны, а какие неизвестны, может не быть предопределено. Соответственно, мог бы быть подготовлен решатель (средство нахождения решения) для многочисленных путей операций нахождения решения даже с использованием одиночной модели. Процесс построения вида карты может быть полностью управляемым данными и может включать в себя механизм для канонизации входных данных и привязки канонизированных входных данных к параметрам модели карты.

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

Краткое описание чертежей

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

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

Фиг.2 иллюстрирует конвейерную среду, которая представляет один из примеров среды по фиг.1;

Фиг.3 схематически иллюстрирует вариант осуществления информационной части конвейера по фиг.2;

Фиг.4 схематически иллюстрирует вариант осуществления аналитической части конвейера по фиг.2;

Фиг.5 схематически иллюстрирует вариант осуществления смотровой части конвейера по фиг.2;

Фиг.6 иллюстрирует визуализацию компоновки вида, которая может конструироваться конвейером по фиг.2;

Фиг.7 иллюстрирует блок-схему последовательности операций способа для формирования компоновки вида с использованием конвейерной среды по фиг.2;

Фиг.8 иллюстрирует блок-схему последовательности операций способа для визуализации компоновки вида в ответ на взаимодействие пользователя с компоновкой вида с использованием конвейерной среды по фиг.2;

Фиг.9 схематически более подробно иллюстрирует решатель аналитической части по фиг.4, включающий в себя набор специализированных решателей;

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

Фиг.11 иллюстрирует визуализацию совмещенной компоновки вида, которая расширяет пример по фиг.6;

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

Фиг.13 иллюстрирует визуализацию городского плана, к которому также могут применяться принципы, описанные в материалах настоящей заявки;

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

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

Фиг.16 иллюстрирует вычислительную систему, которая представляет среду, в которой может быть реализована инфраструктура компоновки по фиг.1 (или ее части).

Подробное описание

Фиг.1 иллюстрирует среду 100 визуальной компоновки, которая может использоваться для построения интерактивной визуальной компоновки. Построение интерактивной визуальной компоновки выполняется с использованием управляемой данными аналитики и визуализации аналитических результатов. Среда 100 включает в себя инфраструктуру 110 компоновки, которая выполняет логику, которая выполняется независимо от проблемной области знаний компоновки 130 вида. Например, такая же инфраструктура 110 компоновки может использоваться для составления интерактивных компоновок вида для планов города, молекулярных моделей, планировок стеллажей магазина бакалейных товаров, анализа работы или сборки машин или других специфичных области визуализаций.

Инфраструктура 110 компоновки использует специфичные области данные 120, однако, для построения реальной визуальной компоновки 130, которая специфична области. Соответственно, одна и та же инфраструктура 110 компоновки может использоваться для построения компоновок вида для любого количества разных областей посредством скорее изменения специфичных области данных 120, чем вынуждения перекодировать саму инфраструктуру 110 компоновки. Таким образом, инфраструктура 110 компоновки конвейера 100 может применяться к потенциально неограниченному количеству проблемных областей, или по меньшей мере к широкому многообразию проблемных областей, посредством скорее изменения данных, чем перекодирования и перекомпилирования. Компоновка 130 вида, в таком случае, может поставляться в качестве команд в надлежащий модуль двухмерной или трехмерной визуализации. Архитектура, описанная в материалах настоящей заявки, также предусматривает удобное включение предварительно существующих моделей компоновки вида в качестве компоновочных блоков в новые модели компоновки вида. В одном из вариантов осуществления многочисленные компоновки вида могут быть включены в совмещенную компоновку вида, чтобы предоставлять возможность для легкого сравнения между двух возможных решений для модели.

Фиг.2 иллюстрирует примерную архитектуру инфраструктуры 110 компоновки в виде конвейерной среды 200. Конвейерная среда 200 включает в себя, среди прочего, сам конвейер 201. Конвейер 201 включает в себя информационную часть 210, аналитическую часть 220 и смотровую часть 230, каждая из которых будет описана подробно по следующим чертежам с 3 по 5, соответственно, и сопроводительному описанию. До настоящего времени, на общем уровне, информационная часть 210 конвейера 201 может принимать многообразие типов данных и представляет такие данные в канонической форме в аналитическую часть 220 конвейера 201. Аналитическая часть 220 привязывает данные к различным параметрам модели и вычисляет неизвестные параметры модели с использованием аналитики модели. Различные значения параметров затем выдаются в смотровую часть 230, которая строит сборный вид с использованием таких значений параметров модели.

Конвейерная среда 200 также включает в себя компонент 240 авторской разработки, который предоставляет автору или другому пользователю конвейера 201 возможность формулировать и/или выбирать данные для выдачи в конвейер 201. Например, компонент 240 авторской разработки может использоваться для подачи данных в каждую из информационной части 210 (представленной входными данными 211), аналитической части 220 (представленной данными 221 аналитики) и смотровой части 230 (представленной данными 231 вида). Различные данные 211, 221 и 231 представляют пример специфичных области данных 120 по фиг.1 и будут описаны гораздо более подробно в дальнейшем. Компонент 240 авторской разработки поддерживает выдачу широкого многообразия данных, в том числе, например, схем данных, фактических данных, которые должны использоваться моделью, местоположения или диапазона возможных местоположений данных, которые должны вноситься из внешних источников, визуальных (графических или анимационных) объектов, взаимодействий интерфейса пользователя, которые могут выполняться над видимыми операторами моделирования (например, видами, уравнениями, ограничениями), привязками, и так далее. В одном из вариантов осуществления компонент авторской разработки является только одной частью функциональных возможностей, предусмотренных общим компонентом диспетчера (не показанным на фиг.2, но представленным инфраструктурой 110 компоновки по фиг.1). Диспетчер является общим управляющим узлом, который управляет последовательностями операций всех других компонентов (таких, как соединители (коннекторы) линий передачи данных, решатели, средства просмотра и так далее) в ответ на события (такие, как события взаимодействия пользователя, события внешних данных и события из любого из других компонентов, таких как решатели, операционная система и так далее).

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

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

Однако в конвейерной среде 200 по фиг.2 компонент 240 авторской разработки используется для выдачи данных в существующий конвейер 201, где они являются данными, которые управляют полной последовательностью операций от определения входных данных к определению аналитической модели, до определения того, каким образом результаты аналитики визуализируются в компоновке вида. Соответственно, не нужно выполнять никакого кодирования, для того чтобы приспосабливать конвейер 201 к любой одной из широкого многообразия областей и проблематики. Единственными данными, поставляемыми в конвейер 201, являются те, которые следует изменить для того, чтобы применить конвейер 201 для визуализации другой компоновки вида из совершенно другой проблемной области знаний, или, возможно, настройки решения проблем для существующей области знаний. Кроме того, поскольку данные могут изменяться во время использования (то есть во время выполнения), а также во время авторской разработки, модель может модифицироваться и/или расширяться во время выполнения. Таким образом, есть меньшее, если таковое имеется, различие между авторской разработкой модели и выполнением модели. Так как вся авторская разработка включает в себя редактирование элементов данных, и так как программное обеспечение выполняет все из своего поведения по данным, каждое изменение в отношении данных немедленно оказывает влияние на поведение без необходимости в перекодировании и перекомпиляции.

Конвейерная среда 200 также включает в себя модуль 250 ответа на взаимодействие пользователя, который обнаруживает, когда пользователь провзаимодействовал с отображенной компоновкой вида, а затем определяет, что следует сделать в ответ. Например, некоторые типы взаимодействий могли бы не требовать никакого изменения в данных, поставляемых в конвейер 201, и таким образом не требовать никаких изменений в отношении компоновки вида. Другие типы взаимодействий могут изменять одни или более из данных 211, 221 или 231. В таком случае эти новые или модифицированные данные могут побуждать новые входные данные выдаваться в информационную часть 210, могли бы требовать повторного анализа входных данных аналитической частью 220 и/или могли требовать повторной визуализации компоновки вида смотровой частью 230.

Соответственно, конвейер 201 может использоваться для расширения управляемых данными аналитических визуализаций, может быть, неограниченным количеством проблемных областей или по меньшей мере широким многообразием проблемных областей. Более того, не требуется быть программистом, чтобы изменять компоновку вида для принятия мер в ответ на широкое многообразие проблематики. Каждая из информационной части 210, аналитической части 220 и смотровой части 230 конвейера 201 далее будет описана по отношению к соответственной информационной части 300 по фиг.3, аналитической части 400 по фиг.4 и смотровой части 500 по фиг.5, в таком порядке. Как будет очевидно из фиг.с 3 по 5, конвейер 201 может быть построен в качестве последовательности компонентов преобразования, где каждый из них 1) принимает некоторые надлежащие входные данные, 2) выполняет некоторое действие в ответ на такие входные данные (такое, как выполнение преобразования над входными данными), и 3) выводит данные, которые затем служат в качестве входных данных в следующий компонент преобразования.

Конвейер 201 может быть реализован на клиенте, на сервере или даже может быть распределенным между клиентом и сервером, без ограничения. Например, конвейер 201 мог бы быть реализован на сервере и выдавать команды визуализации в качестве выходных данных. Браузер на стороне клиента, в таком случае, может только осуществлять визуализацию согласно командам визуализации, принятым с сервера. На другом краю спектра конвейер 201 может содержаться на клиенте с авторской разработкой и/или использованием, выполняемыми на клиенте. Даже если бы конвейер 201 был полностью на клиенте, конвейер 201 по-прежнему мог бы отыскивать источники данных, внешние по отношению к клиенту, ради надлежащей информации (например, модели, соединители, канонизаторы, схемы и другое). Также есть варианты осуществления, которые предусматривают гибрид этих двух подходов. Например, в одном из таких гибридных подходов, модель размещена на сервере, но модули веб-браузера динамически загружаются на клиенте, так что некоторая логика взаимодействия и просмотра модели вынуждена выполняться на клиенте (таким образом предоставляя возможность более обильных и быстрых взаимодействий и видов).

Фиг.3 иллюстрирует только один из многих возможных вариантов осуществления информационной части 300 конвейера 201 по фиг.2. Одна из функций информационной части 300 состоит в том, чтобы выдавать данные в каноническом формате, который совместим со схемами, понимаемыми аналитической частью 400 конвейера, обсужденной по фиг.4. Информационная часть включает в себя компонент 310 доступа к данным, который осуществляет доступ к разнородным данным 301. Входные данные 301 могут быть «разнородными» в том смысле, что данные могут (но не должны) представляться в компонент 310 доступа данных в канонической форме. Фактически, информационная часть 300 структурирована из условия, чтобы разнородные данные могли бы иметь широкое многообразие форматов. Примеры разных видов данных областей знаний, которые могут подвергаться доступу и обрабатываться моделями, включают в себя текстовые (расширяемого языка разметки) и XML-документы, таблицы, списки, иерархии (деревья), результаты SQL-запросов (языка структурированных запросов) баз данных, результаты запросов кубов BI (корпоративного интеллекта), графическую информацию, такую как двухмерные (2D) чертежи и трехмерные (3D) визуальные модели в различных форматах, и их комбинации (то есть смесь). Кроме того, вид данных, которые могут подвергаться доступу, может декларативно расширяться посредством предоставления определения (например, схемы) для данных, которые должны подвергаться доступу. Соответственно, информационная часть 300 дает возможность широкого многообразия разнородных входных данных в модель, и также поддерживает декларативное расширение во время выполнения доступных типов данных.

В одном из вариантов осуществления часть 300 доступа к данным включает в себя некоторое количество соединителей для получения данных из некоторого количества разных источников данных. Поскольку одна из основных функций соединителя состоит в том, чтобы устанавливать соответствующие данные в каноническую форму, такие соединители часто будут упоминаться в дальнейшем и на чертежах как «канонизаторы». Каждый канонизатор может обладать пониманием специальных программных интерфейсов приложения (API) своего соответствующего источника данных. Канонизатор также мог бы включать в себя соответствующую логику для сопряжения с таким соответствующим API, чтобы считывать и/или записывать данные из и в источник данных. Таким образом канонизаторы строят мост между внешними источниками данных и отображением данных в памяти.

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

Однако если входные данные 301 не являются каноническими, то надлежащий компонент 330 канонизации данных способен преобразовывать входные данные 301 в канонический формат. Компоненты 330 канонизации данных фактически являются набором компонентов 330 канонизации данных, каждый из которых способен к преобразованию входных данных, имеющих конкретные характеристики, в каноническую форму. Набор компонентов 330 канонизации проиллюстрирован в качестве включающего в себя четыре компонента 331, 332, 333 и 334 канонизации. Однако многоточие 335 символизирует, что также могут быть другие количества компонентов канонизации, возможно, даже меньшие, чем проиллюстрированные четыре.

Входные данные 301 могут включать в себя даже сам канонизатор, а также идентификацию соотнесенных характеристик(и) данных. Информационная часть 300 затем может регистрировать соотнесенные характеристики данных и выдавать компонент канонизации в набор 330 компонентов канонизации, где он может добавляться к имеющимся в распоряжении компонентам канонизации. Если позже принимаются входные данные, которые имеют свои соотнесенные характеристики, то информационная часть 310 может назначать входные данные на соотнесенный компонент канонизации. Компоненты канонизации также могут отыскиваться динамически из внешних источников, таких как из определенных библиотек компонентов во всемирной паутине. Например, если схема для данного источника данных известна, но необходимый кананонизатор не присутствует, канонизатор может быть обнаружен из внешней библиотеки компонентов при условии, что такая библиотека может быть найдена и содержит в себе необходимые компоненты. Конвейер также мог бы синтаксически анализировать данные, для которых еще не известна никакая схема, и сравнивать результаты синтаксического анализа с информацией о схеме в известных библиотеках компонентов, чтобы сделать попытку динамического определения типа данных, и таким образом локализовать необходимые компоненты канонизатора.

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

В одном из вариантов осуществления информационная часть 310 может быть сконфигурирована для назначения входных данных на компонент канонизации на основе типа файла и/или типа формата входных данных. Другие характеристики, например, могли бы включать в себя источник входных данных. Компонент канонизации по умолчанию может назначаться на входные данные, которые не имеют назначенного соответствующего компонента канонизации. Компонент канонизации по умолчанию может применять набор правил, чтобы попытаться канонизировать входные данные. Если компонент канонизации по умолчанию не способен канонизировать данные, компонент канонизации по умолчанию мог бы инициировать компонент 140 авторской разработки по фиг.1 для приглашения пользователя предоставить определение схемы для входных данных. Если определения схемы еще не существует, компонент 140 авторской разработки мог бы представлять служебную программу определения схемы, чтобы помогать автору формировать соответствующее определение схемы, которая может использоваться для преобразования входных данных в каноническую форму. Как только данные в канонической форме, схема, которая сопровождает данные, выдает достаточное описание данных, чтобы оставшейся части конвейера 201 был не нужен новый код для интерпретации данных. Взамен конвейер 201 включает в себя код, который способен интерпретировать данные в свете любой схемы, которая является выразимым языком объявления схем.

Независимо канонические данные 340 выдаются в качестве выходных данных из информационной части 300 и в качестве входных данных в аналитическую часть 400. Канонические данные могли бы включать в себя поля, которые включают в себя многообразие типов данных. Например, поля могли бы включать в себя простые типы данных, такие как целые числа, числа с плавающей точкой, строки, векторы, массивы, наборы, иерархические структуры, текст, XML-документы, таблицы, списки, результаты SQL-запроса базы данных, результаты запроса куба BI (корпоративного интеллекта), графическую информацию, такую как двухмерные чертежи и трехмерные визуальные модели в различных форматах, или даже сложные комбинации этих различных типов данных. В качестве еще одного преимущества последовательность операций канонизации способна канонизировать широкое многообразие входных данных. Более того, многообразие входных данных, которые способна принимать информационная часть 300, является расширяемым. Это полезно в случае, где комбинируются многочисленные модели, как будет обсуждено позже в этом описании.

Фиг.4 иллюстрирует аналитическую часть 400, которая представляет пример аналитической части 220 конвейера 201 по фиг.2. Информационная часть 300 выдавала канонизированные данные 401 в компонент привязки модели данных, несмотря на то что канонизированные данные 401 могли бы иметь любую канонизированную форму и любое количество параметров, где форма и количество параметров могли бы даже отличаться от одного куска входных данных к другому. Для целей обсуждения, однако, канонические данные 401 имеют поля с 402A по 402H, которые могут коллективно указываться в материалах настоящей заявки как «поля 402».

С другой стороны, аналитическая часть 400 включает в себя некоторое количество параметров 411 модели. Тип и количество параметров модели могут различаться согласно модели. Однако, для целей обсуждения конкретного примера, параметры 411 модели будут обсуждены в качестве включающих в себя параметры 411A, 411B, 411C и 411D модели. В одном из вариантов осуществления идентичность параметров модели и аналитические соотношения между параметрами модели могут декларативно определяться без использования обязательного кодирования.

Компонент 410 привязки модели данных посредничает между полями 402 канонизированных данных и параметрами 411 модели, чтобы, тем самым, обеспечивать привязки между полями. В этом случае поле 402B данных привязано к параметру 411A модели, как представлено стрелкой 403A. Другими словами, значение из поля 402B данных используется для заполнения параметра 411A модели. К тому же в этом примере поле 402E данных привязано к параметру 411B модели (как представлено стрелкой 403B), а поле 402H данных привязано к параметру 411C модели (как представлено стрелкой 403C).

Поля 402A, 402C, 402D, 402F и 402G данных не показаны привязанными к какому бы то ни было из параметров модели. Это должно подчеркнуть, что не всем полям данных из входных данных всегда требуется использоваться в качестве параметров модели. В одном из вариантов осуществления одно или более из этих полей данных могут использоваться для выдачи команд в компонент 410 привязки модели данных о том, какие поля из канонизированных данных (что касается этих канонизированных данных или может быть любых будущих подобных канонизированных данных) должны привязываться и к какому параметру модели. Это представляет пример вида данных 221 аналитики, которые могут выдаваться в аналитическую часть 220 по фиг.2. Определение того, какие поля данных из канонизированных данных привязаны и каким параметрам модели, может быть сформулировано некоторым количеством способов. Например, привязки могут быть 1) явным образом заданы автором во время авторской разработки, 2) явным образом заданы пользователем во время использования (при условии любых ограничений, наложенных автором), 3) автоматической привязкой посредством компонента 240 авторской разработки на основании алгоритмической эвристики, и/или 4) приглашением, от компонента авторской разработки, автора и/или пользователя задать привязку, когда определено, что привязка не может быть произведена алгоритмически. Такие привязки также могут быть разрешены в качестве части самой логики модели.

Возможность автора определять, какие поля данных отображаются и в какие параметры модели, дает автору большую гибкость в способности использовать символы, которыми автору удобно определять параметры модели. Например, если один из параметров модели представляет давление, автор может назвать такой параметр модели «Давлением» или «P», либо любым другим символом, который имеет смысл для автора. Автор может даже переименовывать параметр модели, что в одном из вариантов осуществления могло бы побуждать компонент 410 привязки модели данных осуществлять автоматическое обновление, чтобы дать привязкам, которые были раньше к параметру модели старого наименования, взамен, привязываться к параметру модели нового наименования, тем самым сохраняя требуемые привязки. Этот механизм для привязки также предоставляет привязке возможность декларативно изменяться во время выполнения.

Параметр 411D модели проиллюстрирован звездочкой, чтобы подчеркнуть, что в этом примере параметру 411D модели не было задано значение компонентом 410 привязки модели данных. Соответственно, параметр 411D модели остается неизвестным. Другими словами, параметру 411D модели не задано значение.

Компонент 420 моделирования выполняет некоторое количество функций. Прежде всего компонент 420 моделирования определяет аналитические соотношения 421 между параметрами 411 модели. Аналитические соотношения 421 категоризированы на три основные категории, включающие в себя уравнения 431, правила 432 и ограничения 433. Однако, список решателей является расширяемым. В одном из вариантов осуществления, например, одна или более имитационных моделей могут быть включены в состав в качестве части аналитических соотношений, при условии что соответствующая машина имитационного моделирования предусмотрена и зарегистрирована в качестве решателя.

Термин «уравнение», в качестве используемого в материалах настоящей заявки, встает в один ряд с термином, который и так используется в области математики.

Термин «правила», в качестве используемого в материалах настоящей заявки, означает условное высказывание, где если одно или более условий удовлетворены (условная часть или часть «если» («if») условного оператора), то должны быть предприняты одно или более действий (следственная часть или часть «то» («then») условного оператора). Правило применяется к параметрам модели, если один или более параметров модели выражены в условном операторе, либо один или более параметров модели выражены в следственном выражении.

Термин «ограничение», в качестве используемого в материалах настоящей заявки, означает, что ограничение применяется к одному или более параметрам модели. Например, в модели планирования города элемент конкретного дома может быть ограничен размещением в местоположении карты, которое имеет подмножество всех возможных обозначений районирования. Элемент моста может быть ограничен снизу определенной максимальной длиной или определенным количеством полос движения.

Автор, который является знающим модель, может предоставлять выражения этих уравнений, правил и ограничений, которые применяются к такой модели. В случае имитационных моделей автор мог бы предоставлять надлежащую машину имитационного моделирования, которая выдает надлежащие соотношения имитационной модели между параметрами модели. Компонент 420 моделирования может предусматривать механизм, чтобы автор выдавал естественное символическое выражение для уравнений, правил и ограничений. Например, автор связанной с термодинамикой модели может просто копировать и вставлять уравнения из учебника по термодинамике. Способность привязывать параметры модели к полям данных предоставляет автору возможность использовать любые символы, с которыми автор хорошо знаком (такие, как точные символы, используемые в учебниках, на которые полагается автор) или точные символы, которые автор хотел бы использовать.

Перед решением компонент 420 моделирования также идентифицирует, какие из параметров модели должны быть вычислены (то есть в дальнейшем «выходная переменная модели», если в единственном числе, или «выходные переменные модели», если во множественном числе, или «выходная переменная(ые) модели», если могли бы быть одиночная или множественные выходные переменные модели). Выходные переменные модели могут быть неизвестными параметрами или они могли быть известными параметрами модели, где значение известного параметра модели подвергается изменению в операции нахождения решения. В примере по фиг.4, после операции привязки модели данных, параметры 411 A, 411B и 411C модели известны, а параметр 411D модели неизвестен. Соответственно, неизвестный параметр 411D модели мог быть одним из выходных переменных модели. В качестве альтернативы или в дополнение, один или более известных параметров 411A, 411B и 411C модели также могли бы быть выходными переменными модели. Решатель 440 в таком случае вычисляет выходную переменную(ые) модели, если возможно. В одном из вариантов осуществления, описанных в дальнейшем, решатель 440 способен вычислять многообразие выходных переменных модели, даже в пределах одиночной модели, при условии, что предоставлены входные переменные модели, достаточные чтобы дать возможность выполняться операции нахождения решения. Входные переменные модели, например, могли быть известными параметрами модели, чьи значения не подвергаются изменению во время операции нахождения решения. Например, на фиг.4, если бы параметры 411A и 411D модели были входными переменными модели, решатель вместо этого мог бы взамен вычислять выходные переменные 411B и 411C модели. В одном из вариантов осуществления решатель мог выдавать любой один из некоторого количества разных типов данных для одиночного параметра модели. Например, некоторые операции уравнений (такие, как сложение, вычитание и тому подобные) применяются независимо от того, являются ли операнды целыми числами, с плавающей точкой, векторами таковых или матрицами таковых.

В одном из вариантов осуществления, даже когда решатель 440 не может вычислить конкретные выходные переменные модели, решатель 400 мог бы по-прежнему представлять частичное решение для такой выходной переменной модели, даже если полное решение до фактического численного результата (или какого бы то ни было вычисляемого типа данных) невозможно. Это предоставляет конвейеру возможность облегчить инкрементальную разработку посредством подсказывания автору в отношении того, какой информации необходимо прийти к полному решению. Это также помогает устранять разграничение между временем авторской разработки и временем использования. Для отвлеченного примера предположим, что аналитическая модель включает в себя уравнение a=b+c+d. Далее, предположим, что a, c и d - выходные переменные модели, а b - входная переменная модели, имеющая известное значение 5 (целочисленное в этом случае). В процессе решения решатель 440 способен вычислить только одну из выходных переменных модели, «d», и назначить значение 6 (целочисленное) параметру модели, названному «d», но решатель 440 не способен вычислить «c». Поскольку «a» зависит от «c», параметр модели, названный «a», также остается неизвестным и невычисленным. В этом случае, вместо присваивания целочисленного значения «a», решатель мог сделать частичное решение и вывести строковое значение «c+11» в параметр «a» модели. Как упомянуто ранее, это могло бы быть особенно полезным, когда специалист в определенной области знаний является осуществляющим авторскую разработку аналитической модели, и будет существенно полезным для предоставления частичной информации касательно содержимого параметра «a» модели, и будет также полезным для подачи сигналов автору, что необходимо быть предоставленной некоторой дополнительной аналитике модели, которая даст возможность вычисляться параметру «c» модели. Этот частичный результат решения, возможно, может быть выведен в некоторой форме на компоновке вида, чтобы предоставлять специалисту в определенной области знаний возможность видеть частичный результат.

Решатель 440 показан в упрощенном виде на фиг.4. Однако решатель 440 может направлять работу многочисленных составляющих решателей, как будет описано по фиг.9. На фиг.4 компонент 420 моделирования затем делает параметры модели (в том числе известные в настоящий момент и вычисленные выходные переменные модели) имеющимися в распоряжении в качестве выходных данных, которые должны выдаваться в смотровую часть 500 по фиг.5.

Фиг.5 иллюстрирует смотровую часть 500, которая представляет пример смотровой части 230 по фиг.2. Смотровая часть 500 принимает параметры 411 модели из аналитической части 400 по фиг.4. Смотровая часть также включает в себя хранилище 520 компонентов вида, которое содержит в себе набор компонентов вида. Например, хранилище 520 компонентов вида в этом примере проиллюстрировано в качестве включающего в себя компоненты с 521 по 524 вида, хотя хранилище 520 компонентов вида может содержать в себе любое количество компонентов вида. Каждый из компонентов вида может включать в себя ноль или больше входных параметров. Например, компонент 521 вида не включает в себя никаких входных параметров. Однако компонент 522 вида включает в себя два входных параметра 542A и 542B. Компонент 525 вида включает в себя один входной параметр 543, и компонент 524 вида включает в себя один входной параметр 544. Что упомянуто, это является только примером. Входные параметры могут, но необязательно должны, оказывать влияние на то, каким образом визуализируется визуальный элемент. То обстоятельство, что компонент 521 вида не включает в себя никаких входных параметров, подчеркивает, что могут быть виды, которые формируются без ссылки на какие бы то ни было параметры модели. Рассмотрим вид, который содержит только постоянные (встроенные) данные, которые не изменяются. Такой вид, например, мог составлять нормативно-техническую информацию для пользователя. В качестве альтернативы, рассмотрим вид, который предоставляет только способ для просмотра каталога, так что элементы могут выбираться из него для импорта в модель.

Каждый компонент с 521 по 524 вида включает в себя или ассоциирован с соответствующей логикой, которая, когда выполняется компонентом 540 компоновки вида с использованием соответствующего входного параметра(ов) компонента вида, если таковой имеет место, обеспечивает размещение соответствующего элемента вида в виртуальном пространстве 550. Такой виртуальный элемент может быть статическим изображением или объектом или может быть динамическим анимированным виртуальным элементом или объектом. Например, каждый из компонентов с 521 по 524 вида ассоциирован с соответствующей логикой с 531 по 534, которая, когда выполняется, обеспечивает то, что соответствующий виртуальный элемент с 551 по 554, соответственно, визуализируется в виртуальном пространстве 550. Виртуальные элементы проиллюстрированы в качестве простых форм. Однако виртуальные элементы могут быть довольно сложными по форме, может быть даже включающими в себя анимацию. В этом описании, когда элемент вида визуализируется в виртуальном пространстве, что означает, что компонент компоновки вида создал достаточное количество команд, чтобы, когда выданы в машину визуализации, машина визуализации была способна к отображению элемента вида на отображении в заданном местоположении и указанным образом.

Компоненты с 521 по 524 вида могут выдаваться, может быть, даже в качестве данных вида в смотровую часть 500, например, с использованием компонента 240 авторской разработки по фиг.2. Например, компонент 240 авторской разработки мог бы предусматривать селектор, который дает автору возможность выбирать из нескольких геометрических форм, или, возможно, составлять другие геометрические формы. Автор также мог бы задавать типы входных параметров для каждого компонента вида, тогда как некоторые из входных параметров могут быть входными параметрами по умолчанию, продиктованными смотровой частью 500. Логика, которая ассоциирована с каждым компонентом с 521 по 524 вида, также может быть обусловлена данными вида и/или к тому же может включать в себя некоторые функциональные возможности по умолчанию, предусмотренные самой смотровой частью 500.

Смотровая часть 500 включает в себя компонент 510 привязки вида модели, который сконфигурирован для привязки по меньшей мере некоторых из параметров модели к соответствующим входным параметрам компонентов с 521 по 524 вида. Например, параметр 411A модели привязывается к входному параметру 542A компонента 522 вида, как представлено стрелкой 511A. Параметр 411B модели привязывается к входному параметру 542B компонента 522 вида, как представлено стрелкой 511B. К тому же параметр 411D модели привязывается к входным параметрам 543 и 544 компонентов 523 и 524 вида, соответственно, как представлено стрелкой 511C. Параметр 411C модели не показан привязанным к какому бы то ни было соответствующему параметру компонента вида, подчеркивая, что не всем параметрам модели необходимо использоваться смотровой частью конвейера, даже если такие параметры модели были существенны в аналитической части. К тому же параметр 411D модели показан привязанным к двум разным входным параметрам компонентов вида, символизируя, что параметры модели могут быть привязаны к многочисленным параметрам компонента вида. В одном из вариантов осуществления определение привязок между параметрами модели и параметрами компонентов вида могут быть сформулированы 1) будучи явным образом заданными автором во время авторской разработки, 2) будучи явным образом заданными пользователем во время использования (при условии любых ограничений, наложенных автором), 3) автоматической привязкой посредством компонента 240 авторской разработки на основании алгоритмической эвристики, и/или 4) приглашением от компонента авторской разработки, автора и/или пользователя задать привязку, когда определено, что привязка не может быть произведена алгоритмически.

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

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

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

Конвейер 201 также необычен своей способностью осуществлять анимацию вследствие следующих характеристик.

Во первых, последовательности этапов для переменной анимации могут вычисляться аналитикой модели, в сравнении с наличием только постоянной последовательности этапов на предопределенном диапазоне. Например, в примере изменения рекламных издержек в качестве переменной анимации, представьте себе, что заданное состоит в том, что следует «осуществлять анимацию по рекламным издержкам, где рекламные издержки увеличиваются на 5% для каждого этапа», или «где рекламные издержки имеют значение 10% суммарных издержек для такого этапа». Гораздо более изощренным примером является «осуществить анимацию по рекламным издержкам, где рекламные издержки оптимизированы для максимизации скорости изменения продаж во времени». Другими словами, решатель будет определять набор этапов для рекламных трат во времени (то есть для каждого следующего один за другим периода времени, такого как квартал) из условия, чтобы максимизировался темп роста объема продаж. Здесь, пользователь, предположительно, желает увидеть не только насколько быстро может быть заставлен расти объем продаж изменением рекламных издержек, но также желает узнать поквартальные суммы для рекламных издержек, которые добиваются этого роста (последовательность значений могла бы вычерчиваться в качестве части смешанного визуального представления).

Во-вторых, любая разновидность визуального представления может быть анимирована, а не только традиционные таблицы данных. Например, рассмотрим модель системы автоматизированного проектирования (САПР) реактивного двигателя, который a) должен анимироваться по параметру скорости воздушного потока, и 2) где скорость вращения турбины является функцией скорости воздушного потока, и 3) где температура подшипников турбины является функцией скорости воздушного потока. Реактивные двигатели имеют ограничения на то, насколько быстро турбины могут вращаться до того, как лопатки турбины теряют целостность или перегревается подшипник. Таким образом, в этой анимации, мы желаем, чтобы по мере того как скорость воздушного потока изменяется, цвет лопаток и подшипника турбины изменялся от синего (безопасного) до красного (критического). Значения для «безопасного» и «критического» RPM (числа оборотов в минуту) и температуры подшипников турбины могут хорошо рассчитываться посредством модели, основанной на физических характеристиках таких деталей. Далее, по мере того как анимация изменяет скорость воздушного потока в определенном диапазоне, мы видим, что каждые из лопаток и подшипника турбины изменяют цвет. Что интересно в данный момент состоит в том, чтобы заметить, какие достигают критического значения первыми, и подвергаются ли те или другие внезапному (неконтролируемому росту) добеганию до критического. Эти разновидности эффектов трудны для распознавания посредством просмотра диаграммы или последовательности чертежей, но становятся очевидными немедленно при анимации. Это только один пример осуществления анимации произвольного визуального представления (модели САПР) по произвольному параметру (скорости воздушного потока) с анимацией, кроме того, оказывающей влияние на другие произвольные параметры (RPM и температуру подшипников турбины). Любой параметр(ы) любого визуального представления(ий) может анимироваться согласно любому требуемому параметру(ам), который должен служить в качестве переменных анимации.

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

Как и с другими из возможностей, обсужденных в материалах настоящей заявки, анимации могут быть определены автором, и/или оставлены открытыми, чтобы пользователь осуществлял манипуляции для проверки различных сценариев. Например, модель может подвергаться авторской разработке, чтобы дать некоторым визуальным представлениям возможность анимироваться пользователем согласно параметрам, которые пользователь выбирает сам, и/или в диапазонах данных для переменной анимации, которые выбирает пользователь (включая возможность задавать вычисленные диапазоны, если такие потребуются). Такие анимации также могут отображаться рядом, как в других сравнительных отображениях анализа «что если». Например, пользователь мог бы сравнивать анимацию объема продаж и прибыли во времени, анимированную по времени, в двух сценариях с отличающимися общераспространенными ставкам ссудного процента в будущем, или разными линейными возрастаниями рекламных издержек. В примере реактивного двигателя пользователь мог бы сравнивать анимации двигателя для обоих случаев, до и после изменения конструкции подшипника.

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

Фиг.7 иллюстрирует блок-схему последовательности операций способа 700 для формирования структуры вида. Способ 700 может выполняться конвейерной средой 200 по фиг.2 и таким образом будет описан с частой ссылкой на конвейерную среду 200 по фиг.2, а также со ссылкой на фиг.3-5, каждая из которых показывает отдельные части конвейера по фиг.2. Несмотря на то что способ 700 может выполняться для построения компоновки вида, способ 700 будет описан по отношению к компоновке 600 вида по фиг.6. Некоторые из действий способа 700 могут выполняться информационной частью 210 по фиг.2 и перечислены в левом столбце фиг.7 под заголовком «Данные». Другие из действий способа 700 могут выполняться аналитической частью 220 по фиг.2 и перечислены во втором слева левом столбце фиг.7 под заголовком «Аналитика». Другие из действий способа выполняются смотровой частью 230 по фиг.2 и перечислены во втором справа столбце под заголовком «Вид». Одно из действий может выполняться модулем визуализации и перечислено в правом столбце под заголовком прочие. Любой традиционный или еще только должный быть разработанным модуль визуализации может использоваться для визуализации компоновки вида, построенной в соответствии с принципами, описанными в материалах настоящей заявки.

Со ссылкой на фиг.7 информационная часть осуществляет доступ к входным данным, которые по меньшей мере совместно оказывают влияние на то, какие визуальные элементы отображаются, или каким образом отображаются данные одного или более из визуальных элементов (действие 711). Например, со ссылкой на фиг.6, входные данные могли бы включать в себя компоненты вида для каждого из элементов мебели. Например, каждое из дивана, стула, растений, стола, цветов и даже самой комнаты может быть представлено соответствующим компонентом вида. Компонент вида мог иметь входные параметры, которые пригодны для компонента вида. Если применялась анимация, например, некоторые из входных параметров могли бы оказывать влияние на ход анимации. Некоторые из параметров могли бы оказывать влияние на отображение визуального элемента, а некоторые параметры не могли бы.

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

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

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

Аналитическая часть привязывает входные данные к параметрам модели (действие 721), определяет выходные переменные модели (действие 722) и использует специфичные модели аналитические соотношения между параметрами модели для вычисления выходных переменных модели (действие 723). Операция привязки по действию 721 была обсуждена ранее и, по существу, допускает гибкость в предоставлении автору возможности определять аналитические уравнения, правила и ограничения модели с использованием символов, которые удобны автору модели.

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

Например, в примере комнаты по фэн-шуй фиг.6, предположим, что пользователь купил новый стул для установки в своей гостиной. Пользователь мог бы выдать дизайн комнаты в качестве данных в конвейер. Это могло бы быть облегчено компонентом авторской разработки, предлагающим пользователю ввести размеры комнаты и может быть дать инструмент выбора, который предоставляет пользователю возможность выбрать виртуальную мебель, чтобы перетаскивать и оставлять в виртуальной комнате в надлежащих местоположениях, в которых реальная мебель размещена в реальной комнате. Пользователь, затем, мог бы выбрать элемент мебели, который мог бы редактироваться, чтобы иметь характеристики нового стула, купленного пользователем. Пользователь затем мог бы перетащить и оставить стул в комнате. Измеритель 602 фэн-шуй обновлялся бы автоматически. В этом случае положение и другие атрибуты стула были бы входными переменными модели, а оценки по фэн-шуй были бы выходными переменными модели. По мере того как пользователь перетаскивает виртуальный стул в различные положения, оценки по фэн-шуй измерителя фэн-шуй обновлялись бы, и пользователь таким образом мог бы проверять последствия по фэн-шуй от размещения виртуального стула в различных местоположениях. Чтобы избавить пользователя от вынуждения перетаскивать стул в каждое возможное местоположение, чтобы выяснять, какое дает наилучший фэн-шуй, пользователь может получать локальные визуальные разметки (например, такие как градиентные линии или стрелки), которые указывают пользователю, делает ли перемещение стула в конкретном направлении из его текущего местоположения ситуацию лучше или хуже, и насколько лучше или хуже.

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

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

Далее будет представлен упрощенный пример, который иллюстрирует принципы того, каким образом решатель может перегруппировывать уравнения и изменять обозначение входных и выходных переменных модели, все выделенные из одной аналитической модели. Пользователь не должен сам перегруппировывать уравнения. Упрощенный пример может не точно представлять правила фэн-шуй, но тем не менее иллюстрирует принцип. Допустим, суммарный фэн-шуй (FS) комнаты (FSroom) равняется FS стула (FSchair) и FS растения (FSplant). Допустим, FSchair равен постоянной A, умноженной на расстояние d стула от стены. Предположим, FSplant является постоянной B. Суммарный FS комнаты в таком случае имеет значение: FSroom=A*d+B. Если d - входная переменная модели, то FSroom - выходная переменная модели, и ее значение, отображенное на измерителе, изменяется по мере того, как пользователь переставляет стул. Теперь предположим, что пользователь щелкает кнопкой мыши на измерителе, делая его входной переменной модели и переводя d в состояние выходной переменной модели. В этом случае решатель эффективно и интеллектуально переписывает уравнение, приведенное выше, в качестве d=(FSroom-B)/A. В таком случае компонент вида может перемещать стул повсюду, изменяя d, его расстояние от стены, по мере того как пользователь изменяет требуемое значение, FSroom, на измерителе.

Смотровая часть в таком случае строит вид визуальных элементов (действие 732), выполняя логику построения, ассоциированную с компонентом вида, с использованием входного параметра(ов), если таковой имеет место, возможно, чтобы управлять построением элемента вида в компоновке вида. Построение вида затем может выдаваться в модуль визуализации, который затем использует построение вида в качестве команд визуализации (действие 741).

В одном из вариантов осуществления обработка построения вида рассматривается в качестве преобразования данных, которое выполняется решателем. То есть для данной разновидности вида (например, рассмотрим столбчатую диаграмму) есть модель, состоящая из правил, уравнений и ограничений, которая формирует вид, преобразуя входные данные в отображение, способное выводить структуру данных (названную графом сцены), которая кодирует всю низкоуровневую геометрию и ассоциированные атрибуты, требуемые программным обеспечением визуализации для управления аппаратными средствами машинной графики. В примере столбчатой диаграммы входные данные, например, были бы последовательностью данных, которая должна вычерчиваться, наряду с атрибутами для вещей, подобных названию диаграммы, метки осей, и так далее. Модель, которая формирует столбец, имела бы правила, уравнения и ограничения, которые делали бы вещи, подобные 1) подсчету, из скольких записей состоит последовательность данных, для того чтобы определять, сколько чертить столбцов, 2) расчету диапазона (минимума, максимума), который охватывает последовательность данных, для того чтобы рассчитывать вещи, подобные масштабу, начального/конечного значений для каждой оси, 3) расчету высоты столбца для каждой измерительной точки в последовательности данных на основании ранее рассчитанного масштабного коэффициента, 4) подсчету, сколько символов находятся в названии диаграммы, для того чтобы рассчитывать начальное положение и размер названия, так что название будет надлежащим образом расположено и центрировано по отношению к диаграмме, и так далее. Подводя итог вышесказанному, модель, которая предназначена для расчета набора геометрических форм на основании входных данных, с такими геометрическими формами, сгруппированными в пределах иерархической структуры данных типа «граф сцены». Другими словами, граф сцены является выходной переменной, которую вычисляет модель на основании входных данных. Таким образом, автор может конструировать совершенно новые разновидности видов, переделанные существующие виды и компоновать предсуществующие виды в компоновки, с использованием одной и той же инфраструктуры, которую автор использует для авторской разработки, переделки и компоновки любой разновидности модели. Таким образом, авторы, которые не являются программистами, могут создавать новые виды, не составляя нового кода.

Обращаясь к фиг.2, вспомним, что модуль 250 ответа на взаимодействие пользователя обнаруживает, когда пользователь взаимодействует с компоновкой вида, и побуждает конвейер отвечать надлежащим образом. Фиг.8 иллюстрирует блок-схему последовательности операций способа 800 для ответа на взаимодействие пользователя с компоновкой вида. В частности, модуль ответа на взаимодействие пользователя определяет, какие компоненты конвейера должны выполнять дополнительную работу для того, чтобы обновить вид, и также выдает данные, представленные взаимодействием пользователя, или которые являются по меньшей мере зависимыми от взаимодействия пользователя, в компоненты конвейера. В одном из вариантов осуществления это делается через конвейер преобразования, который работает в обратном (восходящем) направлении вид/аналитика/данные и параллельно (нисходящему) конвейеру данные/аналитика/вид.

Взаимодействия вносятся в качестве событий в восходящий конвейер. Каждый преобразователь в конвейере данные/аналитика/вид предусматривает преобразователь в восходящем направлении (выше по потоку), который обрабатывает поступающие данные взаимодействия. Эти преобразователи могут быть нулевыми (транзитными соединениями, которые оптимизируются вне тракта), или они могут выполнять операцию преобразования над данными взаимодействия, которые должны подаваться дальше в восходящем направлении. Это дает положительные производительность и реактивность конвейера по той причине, что 1) режимы взаимодействия, которые не воздействовали бы на восходящие преобразования, такие как манипулирование видом, которое не воздействует на исходные данные, могут обрабатываться в наиболее подходящей (минимально выше по потоку) точке в конвейере, 2) промежуточные преобразователи могут оптимизировать производительность обновления отправкой эвристически определенных обновлений обратно выше по потоку, впереди финальных обновлений, которые в итоге будут поступать из преобразователей дальше вверх по потоку. Например, по приему взаимодействия редактирования данных, преобразователь уровня вида мог бы производить немедленное обновление вида непосредственно в графе сцены для вида (что касается редакционных правок, которые он знает как интерпретировать) с финальным полным обновлением, приходящим позже от преобразователя данных выше по потоку, где реально редактируются исходные данные.

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

Фиг.8 иллюстрирует блок-схему последовательности операций способа 800 для ответа на взаимодействие пользователя со строением вида. При обнаружении того, что пользователь провзаимодействовал с визуализацией компоновки вида на отображении (действие 801), сначала определяется, требует или нет взаимодействие пользователя обновления вида (этап 802 ветвления). Это может выполняться машиной визуализации, провоцирующей событие, которое интерпретируется компонентом 250 ответа на взаимодействие пользователя по фиг.2. Если взаимодействие пользователя не требует обновления вида (Нет на этапе 802 ветвления), то конвейер не выполняет никакого дополнительного действия для обновления вида (действие 803), хотя сама машина визуализации может выполнять некоторое преобразование над видом. Пример такого взаимодействия пользователя мог бы происходить, если пользователь был должен увеличить контрастность изображения визуализации строения вида или повернуть строение вида. Поскольку такие действия могли предприниматься самой машиной визуализации, конвейеру не нужно выполнять никакую работу для обновления вида в ответ на взаимодействие пользователя.

С другой стороны, если определено, что тип взаимодействия пользователя не требует обновления строения изображения (Да на этапе 802 ветвления), вид обновляется конвейером (действие 704). Это может включать в себя некоторое изменение данных, поставляемых в конвейер. Например, в примере фэн-шуй, предположим, что пользователь был должен переместить положение виртуального стула в пределах виртуальной комнаты, таким образом, изменился бы параметр положения виртуального стула. Возбуждалось бы событие, информирующее аналитическую часть, что соответствующий параметр модели, представляющий положение виртуального стула, также должен изменяться. Компонент аналитики затем повторно вычислял бы оценки по фэн-шуй, перезаполнял бы соответствующие входные параметры измерителя или шкал фэн-шуй, заставляя измеритель фэн-шуй обновляться текущими оценками по фэн-шуй, подходящими для нового положения стула.

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

Инфраструктура решателя

Фиг.9 иллюстрирует среду 900 решателя, которая может представлять пример решателя 440 по фиг.4. Среда 900 решателя может быть реализована в программном обеспечении, программно-аппаратных средствах или комбинации. Среда 900 решателя включает в себя инфраструктуру 901 решателей, которая управляет и координирует работу набора 910 специализированных решателей. Набор 910 проиллюстрирован в качестве включающего в себя три специализированных решателя 911, 912 и 913, но многоточие 914 символизирует, что также могли бы быть другие количества (то есть большие чем три, или меньшие чем три) специализированных решателей. Более того, многоточие 914 также символизирует, что набор 910 специализированных решателей является расширяемым. По мере того как изобретаются и/или разрабатываются новые специализированные решатели, которые могут содействовать аналитике модели, такие новые специализированные решатели могут включаться в набор 910 для дополнения существующих специализированных решателей или, возможно, для замещения одного или более из существующих решателей. Например, фиг.9 иллюстрирует, что новый решатель 915 регистрируется в наборе 910 с использованием модуля 921 регистрации решателей. В качестве одного примера, новый решатель, возможно, мог бы быть решателем имитационной модели, который принимает одно или более известных значений и вычисляет одно или более неизвестных значений. Другие примеры включают в себя решатели для систем линейных уравнений, дифференциальных уравнений, полиномов, интегралов, искатели корней, факторизаторы, оптимизаторы, и так далее. Каждый решатель может работать в численном режиме или в символическом режиме, либо смешанном, численно-символическом режиме. Численные части решений могут приводить в действие параметризованную визуализацию ниже по потоку. Символические части решения могут приводить в действие частичную визуализацию решения.

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

Инфраструктура 901 решателей сконфигурирована для координирования обработки одного или более, либо всех из специализированных решателей в наборе 910, чтобы тем самым обеспечивать вычисление одной или более выходных переменных модели. Инфраструктура 901 решателей в таком случае сконфигурирована для выдачи вычисленных значений в один или более других внешних компонентов. Например, со ссылкой на фиг.2, инфраструктура 901 решателей может выдавать значения параметров модели в смотровую часть 230 конвейера, так что операция нахождения решения, таким образом, оказывает влияние на то, каким образом компоненты вида осуществляют выполнение для визуализации элемента вида, или тем самым оказывает влияние на другие данные, которые ассоциированы с элементом вида. В качестве еще одного потенциального эффекта решения могла бы переделываться сама аналитика модели. Например, только в качестве одного из многих примеров, в которых это могло бы быть реализовано, модель могла бы быть разработана с набором модифицируемых правил так, чтобы в течение данного решения некоторое правило(а) и/или ограничение(я), которые изначально неактивны, становились активированными, а некоторые, которые изначально активированы, становились инактивированными. Уравнения также могут модифицироваться данным способом.

Фиг.10 иллюстрирует блок-схему последовательности операций способа 1000 для инфраструктуры 901 решателей, чтобы координировать обработку между специализированными решателями в наборе 910. Способ 1000 по фиг.10 далее будет описан с частой ссылкой на среду 900 решателя по фиг.9.

Инфраструктура решателей начинает операцию нахождения решения, идентифицируя, какие из параметров модели являются входными переменными модели (действие 1001), а какие из параметров модели являются выходными переменными модели (действие 1002), и идентифицируя аналитику модели, которая определяет соотношение между параметрами модели (действие 1003). При заданной этой информации инфраструктура решателей анализирует зависимости в параметрах модели (действие 1004). Даже при заданном фиксированном наборе параметров модели и при заданном наборе аналитики модели зависимости могут изменяться в зависимости от того, какие параметры модели являются входными переменными модели, а какие являются выходными переменными модели. Соответственно, система может выводить граф зависимостей каждый раз, когда выполняется операция нахождения решения, с использованием идентичности того, какие параметры модели являются входными, и на основании аналитики модели. Пользователю не нужно задавать граф зависимостей для каждого решения. Посредством оценки зависимостей для каждой операции нахождения решения инфраструктура решателей обладает гибкостью для вычисления одного набора из одной или более переменных модели во время одной операции нахождения решения и вычислять другой набор из одной или более переменных модели для следующей операции нахождения решения. В контексте фиг.2-5, который означает большую гибкость, чтобы пользователь задавал, что является входом, а что является выходом, взаимодействуя с компоновкой вида.

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

Если есть выражения, которые имеют одно или более неизвестных, которые могут быть решены независимо, без вычисления сначала других неизвестных в других выражениях (Да на этапе 1005 ветвления), то такие выражения могут решаться в любое время (действие 1006), возможно, даже параллельно с другими этапами вычисления решений. С другой стороны, если есть выражения, которые имеют неизвестные, которые не могут решаться без вычисления сначала неизвестного в другом выражении, то была обнаружена зависимость решения. В таком случае выражение становится частью реляционной структуры (такой, как дерево зависимостей), которая определяет специальную очередность работы по отношению к другому выражению.

В случае выражений, которые имеют взаимосвязанные зависимости решений от других выражений, порядок выполнения специализированных решателей определяется на основании проанализированных зависимостей (действие 1007). Решатели затем выполняются в определенном порядке (действие 1008). В одном из примеров, в случае, где аналитика модели выражена в качестве уравнений, ограничений и правил, порядок выполнения может быть следующим: 1) уравнения с зависимостями, или которые не полностью разрешимы в качестве независимого выражения, переписываются как ограничения, 2) решаются ограничения, 3) решаются уравнения и 4) решаются правила. Решение правил может заставлять данные обновляться.

Как только решатели выполнены в заданном порядке, затем определяется, должно или нет останавливаться нахождение решения (этап 1009 ветвления). Процесс нахождения решения должен останавливаться, например, если вычислены все из выходных переменных модели, или если определено, что хотя вычислены не все из выходных переменных модели, специализированные решатели больше ничего не могут сделать для вычисления большего количества из выходных переменных модели. Если процесс нахождения решения не заканчивается (Нет на этапе 1009 ветвления), последовательность операций возвращается к анализу зависимостей (действие 1004). В этот раз, однако, идентичность входных и выходных переменных модели могла быть изменена вследствие вычисления одной или более переменных модели. С другой стороны, если процесс нахождения решения должен закончиться (Да на этапе 1009 ветвления), нахождение решения заканчивается (действие 1010). Однако, если модель не может быть полностью решена, так как есть слишком много выходных переменных модели, тем не менее, модели может удаваться формирование частичного решения, где выходной переменной модели были присвоены символические значения, отражающие, как далеко решение было способно продолжаться. Например, если модель содержит уравнение A=B+C, и известно, что B должно иметь значение «2» и является входной переменной модели, но C является выходной переменной модели, а A также является выходной переменной модели и имеет необходимость вычисляться, решатель модели не может производить числовое значение для A, поскольку, несмотря на то, что B известно, C неизвестно; значит вместо полного решения решатель возвращает «2+C» в качестве значения для A. Таким образом, автору ясно, какая дополнительная переменная должна стать известной посредством снабжения ее значением или посредством добавления дополнительных правил/уравнений/ограничений или имитационных моделей, которые могут успешно производить необходимое значение из других входных данных.

Способ 1000 может повторяться каждый раз, когда инфраструктура решателей обнаруживает, что было изменение в значении любого из известных параметров модели, и/или каждый раз, когда инфраструктура решателей определяет, что изменилась идентичность известных и неизвестных параметров модели. Решение может развиваться по меньшей мере двумя способами. Во-первых, если модель может быть полностью решена символически (то есть если все уравнения, правила и ограничения могут быть алгоритмически переписаны так, что вычисляемое выражение существует для каждого неизвестного), то таковое делается, а затем вычисляется модель. Другими словами, значения данных формируются для каждого неизвестного, и/или корректируются значения данных, которым дана возможность корректироваться. В качестве второго возможного способа, если модель не может полностью решаться символически, она решается символически частично, а затем определяется, может ли один или более численных методов использоваться для выполнения необходимого решения. Кроме того, происходит этап оптимизации из условия, чтобы даже в первом случае определялось, может ли использование численных методов быть более быстрым способом для вычисления необходимых значений в сравнении с выполнением символического метода решения. Хотя символический метод может быть более быстрым, есть случаи, где символическое решение может выполнять поиски с настолько многими переписываниями выражений и/или настолько многими переписываниями правил, что будет быстрее отказаться от этого и решать с использованием численных методов.

Компоновка сборного вида

Конвейер 201 также включает в себя механизм 241 импортирования модели, который может быть включен в состав в качестве части механизма 240 авторской разработки. Механизм 241 импортирования модели дает пользовательский интерфейс или другую поддержку автору, чтобы предоставлять автору возможность импортировать по меньшей мере часть предварительно существующей управляемой аналитикой модели в текущую управляемую аналитикой модель, которую пользователь строит. Соответственно, автору никогда не нужно начинать с нуля при авторской разработке новой аналитической модели. Импортирование может иметь целую управляемую аналитикой модель или, может быть, часть модели. Например, импортирование может вызывать один или более, либо все из следующих шести потенциально возможных эффектов.

В качестве первого потенциального эффекта импортирования дополнительные входные данные модели могут добавляться в конвейер. Например, со ссылкой на фиг.2 дополнительные данные могли бы добавляться во входные данные 211, данные 221 аналитики и/или данные 231 вида. Дополнительные входные данные модели также могли бы включать в себя дополнительные соединители, добавляемые в компонент 310 доступа к данным по фиг.3, или, возможно, другие компоненты 330 канонизации.

В качестве второго потенциального эффекта импортирования могут быть дополнительные или модифицированные привязки между входными данными модели и параметрами модели. Например, со ссылкой на фиг.4 редактор 410 связей может побуждать дополнительные привязки возникать между канонизированными данными 401 и параметрами 411 модели. Это может вызывать увеличение количества известных параметров модели.

В качестве третьего потенциального эффекта импортирования могут быть дополнительные параметры модели для формирования дополнительного набора параметров модели. Например, со ссылкой на фиг.4 параметры 411 модели могут быть пополнены вследствие импортирования аналитических поведений импортированной модели.

В качестве четвертого потенциального эффекта импортирования могут быть дополнительные аналитические соотношения (такие, как уравнения, правила и ограничения), добавленные в модель. Дополнительные входные данные вытекают из первого потенциального эффекта, дополнительные привязки являются результатом второго потенциального эффекта, дополнительные параметры модели вытекают из третьего потенциального эффекта, и дополнительные аналитические соотношения являются результатом четвертого эффекта. Любые один или более из этих дополнительных элементов могут рассматриваться в качестве дополнительных данных, которые оказывают влияние на компоновку вида. Более того, любые один или более из этих эффектов могли бы изменять поведение решателя 440 по фиг.4.

В качестве пятого потенциального эффекта импортирования могут быть дополнительные или другие привязки между параметрами модели и входными параметрами вида. Например, со ссылкой на фиг.5 компонент 510 привязки вида модели привязывает потенциально пополненный набор параметров 411 модели к потенциально пополненному набору компонентов вида в хранилище 520 компонентов вида.

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

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

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

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

Теперь специалист фэн-шуй мог бы пожелать импортировать базовый элемент круговой диаграммы в качестве основания для построения элемента 602 диаграммы фэн-шуй. Теперь, однако, специалист фэн-шуй мог бы задавать специфичные постоянные входные параметры для элемента диаграммы, может быть учитывая, что всего есть 8 шкал и, возможно, фоновое изображение и наименование для каждой шкалы. Далее, специалисту фэн-шуй необходимо всего лишь задать аналитические соотношения, специфицирующие, как взаимосвязаны параметры модели. Более точно, цвет, положение и тип мебели или другого элемента комнаты могли бы подействовать на конкретную оценку по фэн-шуй. Специалист может просто записывать такие соотношения, чтобы тем самым аналитически взаимосвязывать планировку 601 комнаты и оценку по фэн-шуй. Этот тип совместной возможности надстраивать работу других может порождать гигантскую волну творчества по созданию приложений, которые решают задачи и дают возможность визуального анализа. Это особенно контрастирует с системами, которые могли предоставлять пользователю возможность визуально программировать односторонний поток данных с использованием постоянного графа зависимостей. Такие системы могут делать односторонние решения, направление программируется изначально от входа к выходу. Принципы, описанные в материалах настоящей заявки, предоставляют возможность решений в многочисленных направлениях, в зависимости от того, что известно, а что неизвестно в любой момент времени, при условии интерактивного сеанса с пользователем.

Визуальное взаимодействие

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

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

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

Фиг.11 иллюстрирует совмещенную компоновку 1100 вида, которая продолжается из примера фэн-шуй по фиг.6. В совмещенной компоновке вида первая компоновка 600 вида по фиг.6 представлена еще раз с использованием элементов 601 и 602, в точности, как показанные на фиг.6. Однако здесь есть вторая компоновка вида, которая изображена выделенной. Вторая компоновка вида подобна первой компоновке вида тем, что есть два элемента, отображение комнаты и измеритель оценки по фэн-шуй. Однако входные данные для второй компоновки вида были иными, чем входные данные для первой компоновки вида. Например, в этом случае данные позиционирования для нескольких из элементов мебели были бы разными, тем самым заставляя их положение в планировке 1101 комнаты второй компоновки вида быть иным, чем у планировки 601 комнаты первой компоновки вида. Однако иное положение различных элементов мебели коррелирует с другими оценками по фэн-шуй в измерителе 1102 фэн-шуй второй компоновки вида по сравнению с измерителем 602 фэн-шуй первой компоновки вида.

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

Со ссылкой на фиг.11, также есть механизм 1110 выбора, который предоставляет пользователю возможность визуально подчеркивать выбранное подмножество совокупных имеющихся в распоряжении построенных ранее компоновок вида. Механизм 1110 выбора проиллюстрирован в качестве включающего в себя три возможных строения 1111, 1112 и 1113 вида, которые проиллюстрированы в виде миниатюры или проиллюстрированы некоторым другим неакцентированным образом. Каждая компоновка с 1111 по 1113 вида миниатюры включает в себя соответствующую позицию с 1121 по 1123 для отметки. Пользователь мог бы отмечать позицию для отметки, соответствующую любой компоновке вида, которая должна быть визуально акцентирована. В этом случае отмечены позиции 1121 и 1123 для отметки, тем самым заставляя отображаться большее количество форм соответствующих строений вида.

Совмещенная компоновка вида или даже любая одиночная компоновка вида для такого вопроса может иметь механизм, чтобы пользователь взаимодействовал с компоновкой вида для обозначения того, какие параметры модели должны интерпретироваться в качестве неизвестных, тем самым запуская другое решение посредством механизма аналитического решателя. Например, в отображении 1101 комнаты по фиг.11, могли щелкнуть правой кнопкой мыши на конкретном элементе мебели, щелкнуть правой кнопкой мыши на конкретном параметре (например, положении), и могло бы появиться выпадающее меню, предоставляющее пользователю возможность обозначать, что параметр должен рассматриваться неизвестным. Пользователь затем мог бы щелкнуть правой кнопкой мыши на проценте гармонии (например, 95% в измерителе 1102 оценки по фэн-шуй), после чего мог появиться ползунок (или текстовое окно из другого механизма пользовательского ввода), который предоставляет пользователю возможность задавать разный процент гармонии. Поскольку это имело бы следствием изменение идентичности известных и неизвестных параметров, результатом было бы повторное решение, и элемент мебели, чье положение было задано в качестве неизвестного, мог бы появиться в новом местоположении.

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

Дополнительные примерные применения

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

Дополнительный пример #1 - размещение стеллажей торгового отделения

Продавцы продуктов часто используют трехмерные визуализации для уговаривания розничных торговцев касательно размещений стеллажей, торцевых отображений и новой рекламной деятельности. С конвейером 201 продавец будет способен выполнять анализ «что если» на месте. При заданных размещениях продуктов и при заданном минимальном пороговом значении отношения ежедневных объемов продаж/погонный фут продавец может рассчитывать и визуализировать минимально требуемый наличный запас. Наоборот, при заданном некотором наличном запасе и при заданном двухнедельном цикле пополнения продавец мог бы рассчитывать размещения продукта, который будет давать требуемое отношение объем продаж/погонный фут. Розничный торговец будет способен визуализировать влияние, сравнивать сценарии и сопоставлять выгоды. Фиг.12 иллюстрирует примерную визуализацию размещения стеллажей торгового отделения. Входные данные могли бы включать в себя визуальные изображения продукта, количество продуктов, линейную площадь в квадратных футах, выделенную под каждый продукт, и количество стеллажей для каждого продукта, и так далее.

Дополнительный пример #2 - городское планирование

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

Дополнительный пример #3 - визуальное образование

В областях знаний, подобных науке, медицине и демографии, где сложным данным необходимо осмысливаться не только практикующими специалистами в данной области, но также и общественностью, авторы могут использовать принципы, описанные в материалах настоящей заявки для создания визуализаций данных, которые заинтриговывают и привлекают массовую аудиторию. Они будут использовать специфичные области метафоры и придавать ощущение стиля авторов. Фиг.14 - иллюстрация касательно образования детей. Фиг.15 - традиционная иллюстрация касательно плотности населения. Традиционно, такие визуализации являются совершенно статическими иллюстрациями. С принципами, описанными в материалах настоящей заявки, таковые могут становиться динамическими, интерактивными впечатлениями. Например, посредством ввода географически распределенной схемы роста в качестве входных данных, пользователь мог видеть пиковые изменения численности населения. Некоторые визуализации, где созданная автором модель поддерживает это, будут позволять пользователям выполнять анализ «что если». То есть автор может изменять некоторые значения и наблюдать результат при таком изменении по другим значениям.

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

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

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

Как проиллюстрировано на фиг.16, в наиболее базовой конфигурации, вычислительная система 1600 типично включает в себя по меньшей мере один блок 1602 обработки и память 1604. Память 1604 может быть физической системной памятью, которая может быть энергозависимой, энергонезависимой или некоторой комбинацией этих двух. Термин «память» также может использоваться в материалах настоящей заявки как относящийся к энергонезависимому запоминающему устройству большой емкости, такому как физические запоминающие носители. Если вычислительная система распределенная, возможность обработки, памяти и/или хранения также может быть распределенной. В качестве используемого в материалах настоящей заявки термин «модуль» или «компонент» может соответствовать объектам или процедурам программного обеспечения, которые исполняются в вычислительной системе. Разные компоненты, модули, механизмы и службы, описанные в материалах настоящей заявки, могут быть реализованы в качестве объектов или процессов, которые выполняются в вычислительной системе (например, в виде отдельных потоков команд).

В описании, которое следует, варианты осуществления описаны со ссылкой на действия, которые выполняются одной или более вычислительными системами. Если такие действия реализованы в программном обеспечении, один или более процессоров ассоциированной вычислительной системы, которая выполняет действие, направляют работу вычислительной системы в ответ на исполнение машиноисполняемых команд. Пример такой операции включает в себя манипулирование данными. Машиноисполняемые команды (и подвергаемые манипулированию данные) могут храниться в памяти 1604 вычислительной системы 1600.

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

Варианты осуществления в пределах объема настоящего изобретения также включают в себя машиночитаемые носители для переноса или содержания машиноисполняемых команд или структур данных, хранимых на них. Такие машиночитаемые носители могут быть любыми имеющимися в распоряжении носителями, к которым может быть осуществлен доступ компьютером общего применения или специального назначения. В качестве примера, а не ограничения, такие машиночитаемые носители могут содержать физические запоминающие носители и/или носители памяти, такие как ОЗУ (оперативное запоминающее устройство, RAM), ПЗУ (постоянное запоминающее устройство, ROM), ЭСППЗУ (электрически стираемое программируемое ПЗУ, EEPROM), CD-ROM (ПЗУ на компакт диске) или другое оптическое дисковое запоминающее устройство, магнитное дисковое запоминающее устройство или другие магнитные устройства хранения данных, либо любой другой носитель, который может использоваться для переноса или хранения требуемого средства управляющей программы в виде машиноисполняемых команд или структур данных, и к которым может осуществляться доступ компьютером общего применения или специального назначения. Когда информация переносится или поставляется через сеть или другое соединение связи (соединенное проводами, беспроводное, либо комбинацию соединенного проводами или беспроводного) в компьютер, компьютер, по сути, видит соединение в качестве машиночитаемого носителя. Таким образом, любое такое соединение, по сути, выражается машиночитаемым носителем. Комбинации приведенного выше также должны быть включены в объем машиночитаемых носителей.

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

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

Изобретение относится к средствам построения вида карты, содержащей множество визуальных элементов карты. Техническим результатом является расширение функциональных возможностей за счет обеспечения формирования управляемой данными инфраструктуры компоновки, которая зависит от входных данных. В способе вид карты построен и размещен на месте с использованием логики, определенной компонентом вида карты, соответствующим каждому визуальному элементу, причем такая логика может зависеть от одного или более значений параметров компонента вида карты. Некоторые из этих значений параметров соответствуют известным значениям параметров модели карты, а другие вычисляются с использованием модели, которая определяет аналитические соотношения между параметрами модели карты. Последовательность операций построения вида карты может быть полностью управляемой данными и может включать в себя механизм для канонизации входных данных и привязки канонизированных входных данных к параметрам модели. 3 н. и 17 з. п. ф-лы, 16 ил.

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

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

3. Способ построения вида карты по п.2, в котором аналитические соотношения между множеством параметров модели карты включают в себя по меньшей мере одно уравнение.

4. Способ построения вида карты по п.2, в котором аналитические соотношения между множеством параметров модели карты включают в себя по меньшей мере одно правило.

5. Способ построения вида карты по п.2, в котором аналитические соотношения между множеством параметров модели карты включают в себя по меньшей мере одно ограничение.

6. Способ построения вида карты по п.1, дополнительно содержащий:
действие, на котором визуализируют вид карты на дисплее.

7. Способ построения вида карты по п.1, дополнительно содержащий:
действие, на котором обнаруживают, что пользователь провзаимодействовал с визуализацией вида карты в отображении на дисплее.

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

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

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

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

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

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

14. Машиночитаемый носитель по п.13, в котором вид карты является видом города.

15. Машиночитаемый носитель по п.13, в котором вид карты является видом географического местоположения.

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

17. Машиночитаемый носитель по п.13, в котором вид карты имеет трехмерный объем.

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

19. Машиночитаемый носитель, на котором имеются одна или более машиночитаемых команд, которые при их исполнении одним или более процессорами компьютерной системы предписывают компьютерной системе формировать сборный вид карты визуальных элементов карты с использованием следующего множества конвейерных компонентов:
компонента доступа к данным, сконфигурированного для осуществления доступа к разнородным данным, которые управляют построением сборного вида визуальных элементов;
компонента канонизации данных, который сконфигурирован для представления разнородных входных данных в канонизированном формате;
компонента привязки модели данных, сконфигурированного для привязки частей канонизированных данных из компонента канонизации данных к соответствующим параметрам модели из множества параметров модели карты;
компонента моделирования карты, который 1) задает аналитические соотношения между множеством параметров модели карты, 2) идентифицирует, какие из множества параметров модели карты являются входными переменными модели карты, а какие являются выходными переменными модели карты, 3) вычисляет выходную переменную(ые) модели карты и 4) делает входные переменные модели карты и вычисленные выходные переменные модели карты доступными для компонента визуальной привязки модели, так чтобы значение(я) множества параметров модели карты могло быть привязано к параметру(ам) параметризованных компонентов вида карты;
хранилища компонентов вида, которое приспособлено содержать множество разнородных компонентов вида карты, каждый из которых соответствует визуальному элементу карты, который может отображаться, и по меньшей мере некоторые из которых являются параметризованными;
компонента визуальной привязки модели, сконфигурированного для привязки множества значений параметров модели карты к параметру(ам) по меньшей мере одного из параметризованных компонентов вида карты, содержащихся в пределах хранилища компонентов вида; и
модуля построения вида, сконфигурированного для формулирования команд для визуализации вида карты, который содержит по меньшей мере некоторые из визуальных элементов карты, соответствующих множеству разнородных компонентов вида карты, при этом для по меньшей некоторых из визуальных элементов, которые должны визуализироваться на виде карты, логические средства компонента вида карты, ассоциированные с соответствующим компонентом вида карты, диктуют образ действий, которым происходит визуализация визуального элемента карты, так чтобы визуализация была зависящей от одного или более параметров соответствующего компонента вида карты.

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