Аналитические модели карты

Аналитические модели карты

Иллюстрации

Показать все

Реферат

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

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

В самое последнее время эти визуальные элементы создаются электронным образом, например с использованием приложений систем автоматизированного проектирования (САПР, 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 (целочисленно