Автоматизированная организация данных
Иллюстрации
Показать всеГруппа изобретений относится к средствам автоматизации обработки данных. Техническим результатом является обеспечение управления данными, хранимыми в операционной системе, посредством предоставления определенного конечным пользователем модуля программирования, интегрированного с лежащей в его основе файловой системой. Система содержит модуль программирования для конечного пользователя, интегрированный с лежащей в основе файловой системой и отображающий событие вычислительной системы на автоматическое действие, которое определено конечным пользователем. Система также включает в себя обработчик события, который отвечает на событие и заставляет, по меньшей мере, одно автоматическое действие быть выполненным после обнаружения идентифицированного события; и автоматически выполняют определенное конечным пользователем действие после обнаружения появления идентифицированного события. 3 н. и 16 з.п. ф-лы, 12 ил.
Реферат
Ссылка на связанную заявку
Настоящая заявка испрашивает согласно § 119(e) раздела 35 Свода законов США приоритет предварительной заявки на патент США № 60/657,519 "AUTOMATED DATA ORGANIZATION", поданной 28 февраля 2005 г. Вышеупомянутая заявка, включающая в себя все приложения, тем самым включена по ссылке во всей полноте.
Уровень техники
Современные вычислительные системы могут включать в себя множество программных процессов, активных в любой конкретный момент времени в различных состояниях выполнения. Эти процессы могут быть инициализированы операционной системой, могут контролировать или обслуживать процессы, которые инициализированы в начальный момент времени или после запуска приложения пользователя, или могут быть сами приложением пользователя. Многие, если не большинство, этих процессов или особенностей этих процессов находятся вне способности пользователя осуществлять непосредственное управление. Поэтому, если функциональные возможности, предлагаемые этими процессами, должны быть доступны вообще, такой доступ обычно должен быть выполнен другим программным процессом.
Программные приложения управляют информацией от имени конечных пользователей. Число программных приложений или процессов, выполняющихся на вычислительной системе, в общем случае является функцией количества данных, которое система должна обработать, и числа задач, которое система призвана исполнить. Наименее эффективными частями этих вычислительных режимов работы являются те, которые требуют взаимодействия с человеком. Несмотря на все более и более увеличивающуюся мощность машин, конечные пользователи обычно должны вручную обрабатывать большое количество компьютеризированной информации.
Одним из главных компонентов вычислительной системы общего назначения является запоминающее устройство, такое как накопитель на жестком диске, которое обычно используется для постоянного хранения электронной информации, например файлов данных и выполнимых программ. Чтобы организовать электронную информацию так, чтобы она могла быть расположена и извлечена в пригодной для использования форме, может использоваться файловая система. Существует множество файловых систем, но все они обычно обеспечивают концептуальный организационный уровень для формата и расположения информации на запоминающем устройстве.
Этот концептуальный организационный уровень, обеспеченный файловой системой, может использоваться программными процессами, например процессами операционной системы, для создания, доступа, извлечения, удаления и иным образом управления информацией, сохраненной на запоминающем устройстве. Чтобы защищать целостность файловой системы и гарантировать приверженность формату файловой системы, обычно только некоторым привилегированным программным процессам, подобным процессам ввода/вывода операционной системы, разрешен непосредственный доступ к файловой системе. Приложения и пользователи, которые обращаются (осуществляют доступ) к файловой системе, обычно должны делать это с помощью функций, предоставляемых операционной системой. Эти функции обычно скрыты от представления конечным пользователям, которые могут даже не знать о существовании этих функций. Обычно этот ограниченный доступ приводит к неспособности пользователя полностью использовать особенности файловой системы, чтобы сделать вычислительные задачи проще, например использовать атрибуты файловой системы для автоматизации задач, например, организации или расположения файлов.
Обычно конечный пользователь управляет информацией со своего компьютера согласно циклу жизни информации. В течение этого цикла жизни конечный пользователь обычно создает информацию или получает информацию из некоторого источника, и информация затем сохраняется в файловой системе. В некоторый момент конечный пользователь извлекает информацию и предпринимает меры на основании этой информации - этот цикл может быть повторен много раз. Современные системы не обеспечивают конечному пользователю возможность автоматизации части этого цикла жизни способами, которые являются эффективными и индивидуализированными к потребностям конечного пользователя.
Сущность изобретения
Ниже представлено упрощенное изложение для обеспечения основного понимания. Это изложение не является обширным обзором. Оно не предназначено ни для идентификации ключевых/критических элементов, ни для очерчивания объема. Единственная цель состоит в том, чтобы представить некоторые концепции в упрощенной форме в качестве вводной части к более подробному описанию, представленному ниже. Дополнительно используемые здесь заголовки разделов обеспечиваются просто для удобства и не должны быть никаким образом приняты как ограничение.
Модуль программирования (для) конечного пользователя предоставляет возможность конечным пользователям вычислительной системы идентифицировать события, которые могут служить в качестве инициаторов для одного или более определяемых пользователем действий. Конечные пользователи, используя этот модуль, могут определять задачи по обработке данных, которые должны быть автоматически выполнены при появлении выбранного случая. Эти задачи по обработке данных могут включать в себя организацию файлов и фильтрацию файлов по атрибутам или содержанию (контенту) помимо других задач. Исполнение таких задач может быть осуществлено одним или более компонентами вычислительной системы. Таким образом, с помощью модуля программирования (для) конечного пользователя пользователи могут формировать настроенные конечным пользователем программы, которые помогают в хранении и организации данных.
Программы конечного пользователя, созданные с помощью модуля программирования конечного пользователя, могут быть созданы из одного или более базовых типов, которые могут быть объединены для формирования сложных объектов, которые могут использоваться для выполнения задач. Базовые типы могут быть далее объединены с другими компонентами, так чтобы выполнять более сложные задачи. Действия, которые должны быть выполнены, могут быть инициированы автоматически предварительно выбранным событием без необходимости для конечного пользователя инициализировать эти действия или взаимодействовать с вычислительной системой в то время, как выполняются задачи. Поэтому вместо необходимости выполнять обзор данных и принимать решения относительно того, где сохранить такие данные, пользователь может посредством использования вышеупомянутых базовых типов вынуждать такие данные автоматически фильтроваться и сохраняться в требуемом местоположении. Кроме того, могут быть автоматически предприняты действия при появлении события (например, прием данных). В одном примере пользователь может задать, что каждый раз при приеме сообщения по электронной почте от конкретного индивидуума будет вызвано приложение мгновенной передачи сообщений, и мгновенное сообщение будет доставлено по адресу конкретного контакта. Таким образом, можно видеть, что заданные действия могут происходить для неравноправных приложений посредством использования базовых типов (или комбинации базовых типов). В другом примере действия, определенные пользователем, могут быть явно вызваны командой от конечного пользователя.
Чтобы облегчить применимость, система программирования конечного пользователя может быть интегрирована с файловой системой, чтобы предоставить однородный интерфейс к информации, сохраненной на вычислительной системе. Интеграция между модулем программирования конечного пользователя и файловой системой обеспечивает возможность для конечного пользователя определять правила и действия, которые нужно предпринять в отношении сохраненных данных, причем могут быть применены правила и предприняты действия в отношении данных совместно или без взаимодействия с пользователем. Этот тип программирующей системы (для) конечного пользователя может обеспечивать конечного пользователя способностью управлять данными, используя функции лежащей в основе файловой системы, которая иначе может быть скрыта и к которой будет запрещен доступ конечного пользователя.
Раскрытые и описанные компоненты и способы содержат признаки, описанные ниже и конкретно указанные в формуле изобретения. Нижеследующее описание и прилагаемые чертежи подробно представляют некоторые иллюстративные аспекты. Эти аспекты являются показательными, однако компоненты и способы могут использоваться только некоторыми из различных раскрытых путей. Конкретные варианты выполнения раскрытых и описанных компонентов и способов могут включать в себя некоторые, многие или все такие компоненты, способы и их эквиваленты. Модификации конкретных вариантов выполнения и примеров, представленные ниже, станут очевидны из нижеследующего подробного описания при рассмотрении совместно с чертежами.
Краткое описание чертежей
Фиг.1 изображает блок-схему системы программирования (для) конечного пользователя.
Фиг.2 - блок-схему системы обработки (для) конечного пользователя.
Фиг.3 - схематичную диаграмму схемы правил.
Фиг.4 - схематичную диаграмму системы программирования конечного пользователя с интегрированной файловой системой.
Фиг.5 - схематичную блок-схему системы программирования конечного пользователя с интегрированной файловой системой.
Фиг.6 - схематичную блок-схему системы программирования конечного пользователя с интегрированной файловой системой.
Фиг.7 - схематичную блок-схему системы программирования конечного пользователя с интегрированной файловой системой.
Фиг.8 - блок-схему операций общего способа обработки, который может использоваться вместе с компонентами, которые раскрыты и описаны здесь.
Фиг.9 - блок-схему операций общего способа обработки, который может использоваться вместе с компонентами, которые раскрыты и описаны здесь.
Фиг.10 - схему цикла жизни информации.
Фиг.11 - блок-схему примерного сетевого окружения.
Фиг.12 - блок-схему примерной рабочей среды.
Подробное описание изобретения
Используемые в настоящей заявке термины "компонент", "система", "модуль" и т.п. предназначены для указания на относящийся к применению компьютера объект, такой как аппаратные средства, программное обеспечение (например, при выполнении) и/или программно-аппаратные средства. Например, компонентом может быть процесс, выполняющийся на процессоре, процессор, объект, выполняемая программа, программа и/или компьютер. Так же как приложение, выполняющееся на сервере, так и этот сервер могут быть компонентами. Один или более компонентов могут постоянно находиться в процессе, и компонент может быть расположен на одном компьютере и/или распределен между двумя или больше компьютерами.
Раскрытые компоненты и способы описаны со ссылками на чертежи, на которых аналогичные числовые обозначения используются для ссылок на аналогичные элементы. В нижеследующем описании с целью объяснения многочисленные конкретные подробности приведены для того, чтобы обеспечить полное понимание раскрытого предмета изобретения. Может быть очевидно, однако, что некоторые из этих конкретных подробностей могут быть опущены или объединены с другими в конкретном выполнении. В других случаях некоторые структуры и устройства показываются в форме блок-схем, чтобы облегчить описание. Дополнительно, хотя конкретные сформулированные примеры могут использовать терминологию, которая совместима с архитектурой клиент/сервер или даже могут быть примерами реализации клиент/сервер, специалистам в данной области техники понятно, что роли клиента и сервера могут быть полностью изменены, так что раскрытые и описанные компоненты и способы не ограничены архитектурой клиент/сервер и могут быть легко адаптированы для использования в других архитектурах, в частности, включая одноранговую (P2P) архитектуру, без отрыва от формы или объема раскрытых и описанных компонентов и способов. Далее, следует отметить, что, хотя представленные здесь конкретные примеры включают в себя или ссылаются на конкретные компоненты, реализация компонентов и способов, раскрытых и описанных здесь, не обязательно ограничена такими конкретными компонентами и может также использоваться в других контекстах.
Основанные на искусственном интеллекте системы (например, явно и/или неявно обученные классификаторы) могут быть использованы совместно с выполнением логического вывода, и/или вероятностных определений, и/или основанных на статистике определений в соответствии с одним или более аспектами настоящего изобретения, как описано ниже. Используемый термин "логический вывод" относится в целом к процессу рассуждения или логическому выводу в отношении состояний системы, среды и/или пользователя, исходя из набора наблюдений, которые зафиксированы (захвачены) посредством событий и/или данных. Логический вывод может использоваться для идентификации специфического контекста или действия или может, например, генерировать распределение вероятности на основании состояний. Логический вывод может быть вероятностным, то есть вычислением распределения вероятности по состояниям, представляющим интерес, на основании рассмотрения данных и событий. Логический вывод может также относиться к способам, используемым для создания событий более высокого уровня из набора событий и/или данных. Такой логический вывод приводит к конструированию новых событий или действий из набора наблюдаемых событий и/или сохраненных данных о событиях, действительно ли события являются коррелированными в малой временной близости и исходят ли события и данные из одного или нескольких источников событий и данных или нет. Различные схемы и/или системы классификации, например машины опорных векторов, нейронные сети, экспертные системы, байесовские доверительные сети, нечеткая логика и механизмы слияния данных, помимо прочих, могут использоваться в связи с выполнением действия по автоматическому и/или логическому выводу в связи с компонентами и способами, раскрытыми и описанными ниже.
Фиг.1 изображает схематичную блок-схему системы 100 программирования (для) конечного пользователя. Система 100 программирования конечного пользователя включает в себя операционную платформу 110, которая может обеспечивать среду обработки для системы 100 программирования конечного пользователя. В этом контексте операционная платформа 110 может включать в себя и аппаратные, и программные компоненты. В частности, операционная платформа 110 может быть операционной системой для персонального компьютера, автоматизированного рабочего места или сервера. Событие 120 может быть создано операционной платформой 110, причем событие 120 может служить индикатором того, что задача обработки выполняется или была выполнена. Событие, такое как событие 120, может быть обнаружено другими вычислительными компонентами и может использоваться в качестве инициирующего устройства, чтобы инициализировать выполнение заранее определенной вычислительной задачи.
Модуль 130 программирования (для) конечного пользователя (МПКП, EUP) может обеспечивать компонент, который может использоваться конечным пользователем для определения действия, такого как определяемое пользователем действие 140, которое должно быть предпринято при появлении события 120. Следует отметить, что определяемое пользователем действие 140 может быть единственной задачей или может быть группой задач, которые должны быть выполнены. Модуль 130 EUP может обеспечивать интерфейс к системным функциям, которые могут использоваться вручную или предварительно могут быть только доступны другим программным компонентам, таким как, но не ограничиваясь ими, операционная система или сервисный компонент.
Во время работы конечный пользователь обращается к модулю 130 EUP, чтобы идентифицировать событие, такое как событие 120, которое может использоваться для инициирования определяемого пользователем действия. Конечный пользователь также определяет действие или группу действий, которые конечный пользователь хочет, чтобы система выполнила автоматически при появлении этого идентифицированного события. Это событие затем связывается с определяемым пользователем действием, другими словами, при появлении события 120 операционная платформа исполняет заданное (определенное) пользователем действие.
Например, конечный пользователь может идентифицировать прием сообщения электронной почты от конкретного человека в качестве инициирующего (запускающего) события. Конечный пользователь может затем создать действие так, чтобы после приема такого сообщения электронной почты сообщение было передано в определенную папку "почтового ящика", ответ, подтверждающий получение сообщения, послан отправителю, документ извлечен из файл-сервера и открыт в соответствующей программе, и услышаны звуки предупреждения для уведомления пользователя о том, что документ подготовлен на компьютере. Эти этапы могут быть выполнены автоматически, без вмешательства пользователя посредством использования системы 100.
Фиг.2 изображает схематичную блок-схему системы 200 обработки (для) конечного пользователя. Система 200 обработки конечного пользователя включает в себя интерфейс 210 пользователя, который может обеспечивать доступ к системе для человека-пользователя. Интерфейсом 210 пользователя может быть любой подходящий человеко-машинный интерфейс, например графический пользовательский интерфейс, интерфейс командной строки или интерфейс на основе Web, помимо прочих, и может быть подсоединен к операционной платформе 220, которая может включать в себя и аппаратные, и программные компоненты. Интерфейс 210 пользователя также может быть связан с обработчиком 230 событий и хранилищем 240 данных о правилах, причем обработчик 230 событий может обнаруживать появление события 245 и обращаться к подсистеме 250 обработки.
Во время работы интерфейс 210 пользователя обеспечивает доступ к обработчику 230 событий и хранилищу 240 данных о правилах для конечного пользователя, который может идентифицировать событие, подлежащее использованию в качестве запускающего (инициирующего) события и вызвать связывание этого события с определяемым пользователем действием. Определяемое пользователем действие может быть затем, в свою очередь, сохранено в хранилище 240 данных о правилах. Операционная платформа 220 создает событие 245, которое обнаруживается обработчиком 230 событий, которое может обращаться к хранилищу 240 данных о правилах, чтобы определить, связано ли определяемое пользователем действие с обнаруженным событием. Если это так, обработчик 230 событий обращается к подсистеме 250 обработки, чтобы управлять выполнением определяемого пользователем действия.
Правила, которые нужно применить в течение создания или выполнения определенных конечным пользователем задач, могут соответствовать алгебре правил. Подробности соответствующей алгебры правил, которая может использоваться, могут значительно изменяться согласно конкретному выполнению модуля EUP. Один пример алгебры правил представлен и описан более подробно ниже. Примерная алгебра правил может включать в себя различные логические компоненты, которые могут быть объединены для формирования платформы правил. Среди таких компонентов находятся базовые элементы, которые могут служить в качестве стандартных (компоновочных) блоков для других элементов (терминов) и выражений. Термины и выражения, которые были сформированы из других терминов или выражений, могут самостоятельно использоваться в качестве стандартных блоков для создания более сложных терминов или выражений. Таким образом, могут быть созданы все более и более сложные правила для применения во время выполнения конкретной задачи конечного пользователя.
Property(T) может описывать свойство типа T для конечного пользователя. Конечный пользователь может использовать свойство или свойства, чтобы описать другой логический компонент, такой как фильтр или действие. Свойством может быть некоторый общий дескриптор типа Т для конечного пользователя. При применении к различным типам, таким как T или Т-прим, может использоваться один и тот же дескриптор. Таким образом, Property(T) и Property(Т-прим) могут оба использоваться в качестве дескрипторов и могут быть различными компонентами. Правило, которое имеет тип Т входного элемента и тип О выхода, может быть определено как свойство типа O по типу T.
Filter(T) может быть булевой (логической) функцией, которая может использоваться в качестве фильтра по элементам типа T. В частности, Filter(T) может быть правилом, которое возвращает тип Boolean как результат выполнения правила при обработке. Правило Filter(T), которое применяется к набору элементов, может фильтровать элементы, которые не удовлетворяют условию правила, посредством проверки значения для типа Boolean, возвращенного после выполнения Filter(T), для отдельного элемента в наборе. Элемент, который удовлетворяет условию правила Filter(T), может запрашивать примененное правило Filter(T) для возврата значения "True" ("Истинно") для возвращенного типа Boolean.
Подобным образом элемент, который не удовлетворяет условию примененного правила Filter(T), может запрашивать правило Filter(T) возвратить значение "False" ("Ложь") для возвращенного типа Boolean. Правило Filter(T) может итерационно применяться к каждому элементу в наборе, чтобы получить поднаборы элементов, которые или удовлетворяют, или не удовлетворяют условию примененного правила Filter(T). Таким образом, могут быть созданы включающие или исключающие поднаборы. Включающий поднабор может иметь элементы, которые удовлетворяют условию примененного правила Filter(T) и которые запрашивают возвращенное булево (логическое) значение "Истинно", приводя к тем элементам, которые описаны как включающие. Исключающий поднабор может иметь элементы, которые не удовлетворяют условию примененного правила Filter(T) и которые запрашивают возвращенное булево значение "Ложь", приводя к тем элементам, которые описываются как исключающие. Любой поднабор может использоваться в дальнейшей обработке.
Action(T) (действие) может быть создано как метод элемента типа T, причем этот метод может иметь некоторый побочный эффект, который создает результат. Как правило, Action(T) может использовать или требовать других параметров. Правило, имеющее входной тип T и выдающее замкнутое множество, может определять действие над элементами типа T. Set(T) является группировкой элементов типа T.
Event(T) (событие) может использоваться для определения некоторого появления, представляющего интерес, и обычно ассоциируется с элементом данных, например данными события типа T. Event(T) может использоваться для определения простого события или может использоваться как стандартный блок для создания более сложного события, используя двоичную алгебраическую операцию. При объединении с Filter(T) Event(T) может использоваться для создания полученного (выведенного, Derived) Event(T). В алгебраических терминах:
DerivedEvent(T) = Event(T) + Filter (T).
Вообще, выведенное событие может быть создано, применяя фильтр к событию. Другие конструкции также могут быть сформированы, используя алгебраические принципы. Например, два фильтра по дополнительным типам элемента (например, два типа, которые оба являются подтипами одного и того же родительского типа) могут быть объединены следующим образом:
Filter(T) = Filter1(T_subtype_1) объединение Filter2(T_subtype_2).
Пакет может определять ориентированную на набор задачу, которая должна быть выполнена программным модулем. Семантика пакета может быть определена так, чтобы привести к выполнению некоторого, заранее определенного действия над каждым элементом в наборе. Как и с другими модулями, пакет может быть выполнен после ручной команды или после автоматического появления некоторого события. Пакет (Batch) может быть создан, объединяя набор с действием следующим образом:
Batch = Set(T) + Action(T).
Агент может определять некоторое действие, которое должно быть выполнено при появлении заранее определенного события, где заранее определенное событие может служить как инициатор, который может активизировать выполнение агента и исполнение действия, связанного с агентом. В алгебраических терминах:
Agent = Event(T) + Action(T).
Правила могут быть созданы, используя ряд условий, которые могут быть связаны некоторым логическим способом. Для каждого правила условия могут быть составлены рядом способов. Например, элементы, имеющие заданное свойство, могут быть описаны, используя:
<Свойство> < оператор сравнения > <выражение>
< Существующий фильтр >
ANY/EVERY <назначение отношения> MATCHES <фильтр>
(ЛЮБОЙ/КАЖДЫЙ <назначение отношения> СОВПАДАЕТ <фильтр>)
ANY/EVERY <назначение отношения> IN < набор >
(ЛЮБОЙ/КАЖДЫЙ <назначение отношения> В < набор >).
Другие условия также возможны и могут использоваться для составления правила.
Отдельные логические компоненты EUP могут быть оценены внутри приложения. Такие оценки могут быть выполнены в качестве фоновых задач и поэтому могут быть невидимыми для пользователя. Дополнительно или альтернативно эти задачи могут быть явно выполнены, подчиняясь команде, введенной пользователем. Вообще, несколько типов программ могут использоваться в качестве основной группы программ. Например, основной тип, такой как производный набор, может быть полностью программой конечного пользователя. Когда производный набор активизируется или выполняется, могут быть выполнены команды, связанные с логикой определения набора, и отображены результаты этого выполнения. Дополнительно производные наборы могут использоваться в алгебраических операциях. Например, два производных набора могут быть объединены следующим образом:
Set(T) = Set1(T) Объединение Set2(T).
В качестве другого примера агенты могут быть созданы для исполнения заданных действий при появлении заранее определенных событий. Как определено выше, Агент является событием Event(T), объединенным с действием Action(T). При появлении части события агента могут быть выполнены этапы обработки части действия агента. Таким образом, выполнение агента может быть запущено без какого-либо вмешательства конечного пользователя.
К алгебре EUP можно обращаться через интерфейс прикладных программ (API), который может обеспечивать средства для доступа к типам и операциям объекта, предписанным алгеброй правил. Дополнительно API может предоставлять группу заранее определенных компонентов, таких как заранее сконструированные логические компоненты EUP, которые могут быть доступны непосредственно в качестве альтернативы к конструированию таких компонентов из базовых терминов.
Фиг.3 изображает схематическую диаграмму иерархии 300 типов правил. Схема иерархии 300 типов правил может использоваться для организации типов в один или более функционирующих компонентов, таких как события, правила или программы конечного пользователя, как описано здесь. Дополнительно или альтернативно некоторый другой компонент или вариант одного или более этих описанных компонентов может быть создан согласно подробностям конкретного варианта выполнения. Созданные событие, правило или программа конечного пользователя могут использоваться по одиночке или в комбинации, по необходимости, чтобы выполнять некоторую задачу по обработке данных в зависимости от подробностей компонентов, которые собраны или определены конечным пользователем. В примере, представленном на этой фиг.3, событие может быть событием правила, например событием 320 правила, которое может запускать выполнение исполняемого компонента. Правило может быть логикой правила, например логикой 330 правила, которая может определять логику, которую нужно применить к вычислительному сценарию. Программа правила, например программа 340 правила, может быть программой конечного пользователя или другим выполнимым компонентом. В этом конкретном примере каждое из события 320 правила, логики 330 правила и программы 340 правила может быть связано с одним или более подкомпонентами. Соответственно, каждый из этих подкомпонентов может, например, быть простым типом элемента, например событием, или может вместо этого быть созданным конечным пользователем или сложным типом, например производным набором.
Компонент 320 события правила может быть базовым типом для всех типов событий, используемых агентами платформы правил, созданными конечными пользователями, и может быть концептуально абстрактным и служить для обеспечения общего типа, на который может ссылаться каждый агент. Агент может ссылаться к экземпляру компонента события правила, например компонента 320 события правила, который может уведомлять агента, когда выполнять или запускать такое выполнение. Компонент 320 события правила может, например, являться или быть связанным с основным событием, например базовым 322 событием или производным (выведенным) событием, например фильтрованным событием 324. В одном примере базовое событие 322 может быть выведено из компонента 320 события правила. Тип базового события, например базового события 322, может действовать как перехватчик прерываний для приложения, чтобы подать входной элемент к системе правил, чтобы представить запуск логического события. Например, базовое событие может представлять такие события, как элемент, добавляемый в хранилище данных, или элемент хранилища данных, помимо прочего. Подача входного элемента посредством элемента события может сообщать факт, что событие произошло, и начинать процесс, который может приводить к запуску другого события.
Фильтрованное событие 324 может также быть выведено (произведено) из компонента 320 события правила. Фильтрованное событие 324 может включать в себя ссылку на другое событие правила и ссылку на экземпляр типа для логики фильтра для использования с целью фильтрования запуска события. Фильтрованное событие 324 может запускаться на основании запуска его исходного компонента события правила, например компонента 320 события правила. После запуска исходного события (события-источника) фильтрованное событие 324 может принимать входной элемент, по которому событие-источник было запущено, и оценивать экземпляр его компонента логики фильтра по входному элементу. Фильтрованное событие 324 будет запущено, если и только если логика фильтра выдает оценку "Истина". В этом примере фильтрованное событие, например фильтрованное событие 324, не может возникнуть непосредственно, используя обращение к функции API, а скорее может возникнуть, только когда запущено его событие-источник, и его логика фильтра выдает оценку "Истина" для входного элемента, по которому запущено событие-источник.
Компонент 330 логики правил может быть описан в качестве правила в том смысле, что компонент логики правил может иметь определенные этапы обработки, которые могут привести одну или более вычислительных задач к выполнению компонентом, который использует или иначе связан с компонентом 330 логики правил. Компонент 330 логики правил может являться или быть связан с логикой 332 фильтра, логикой 334 свойств, логикой 336 действий и логикой 338 ассоциаций. Логика 332 фильтра, логика 334 свойств, логика 336 действий и логика 338 ассоциаций могут использоваться для создания логики правил. Логика 332 фильтра может определять логику правил, которая фильтрует заданный экземпляр элемента входного типа. Выходной тип для логики 332 фильтра может быть булевым значением или пустым (null) значением. Логика 334 свойств может также определять правило. Определенное правило может вычислять значение заданного типа, когда задан конкретный экземпляр элемента, и поэтому может выступать как вычисленное свойство. Чтобы поддерживать эту концепцию, выходной тип логики 334 свойств может быть представлен как тип свойства.
Логика 336 действий может определять правило, которое может генерировать последовательность действий для выполнения, когда задан конкретный экземпляр элемента указанного (специфицированного) входного типа. Выход логики 336 действий может быть объектом, который является перечислимым и который кодирует последовательность действий, которые должны быть выполнены. Логика 338 ассоциаций может быть выведена из определения правила и может определять правило, которое может генерировать набор элементов заданного целевого типа, когда задан конкретный экземпляр элемента типа источника. Выход логики 338 ассоциаций может быть экземпляром перечислимого элемента, который составляет набор элементов.
Один класс терминов, описанных этой примерной алгеброй правил, включает в себя выполняемые компоненты. Эти выполняемые компоненты сами не включают в себя логические инструкции, а скорее являются программами-оболочками, которые могут создаваться конечным пользователем и служить для связывания вместе определения логики правил с входными коллекциями. Одним выполняемым компонентом может быть программа 340 правил. Эта программа 340 правил может формировать общий базовый тип для типов программы конечного пользователя. Главная функция программы 340 правил может заключаться в том, чтобы все экземпляры типов программы конечного пользователя, такие как пакеты и агенты, можно было продолжать хранить, их можно было извлечь и можно было отфильтровать на основании такого общего входного типа.
Программа 340 правил может являться или быть связанной с другими компонентами, такими как запрос 342, агент 344 и пакет 346. Запрос 342 может представлять вычисленный результирующий набор элементов, которые могут быть оценены в соответствии со стриктурами (границами) запроса. Агент 344 может представлять действие или действия, которые должны быть выполнены после запуска события или появления некоторого события. Пакет 346 может представлять действие или действия, которые должны быть выполнены над коллекцией элементов. Конечный пользователь может комбинировать эти компоненты множеством способов для создания выполняемой программы правил.
Фиг.4 схематично представляет блок-схему системы 400 программирования (для) конечного пользователя, которая включает в себя интегрированную файловую систему. Система 400 программирования конечного пользователя может выводить поддержку для своих функций программирования из специфических особенностей (свойств) этой лежащей в основе файловой системы. В частности, интеграция системы EUP с подходящей лежащей в основе файловой системой может обеспечивать основание, на котором каждый аспект вычислительной системы может быть сделан программируемым, с которым взаимодействует конечный пользователь.
Система 400 программирования конечного пользователя включает в себя интерфейс 410 пользователя, который может быть любым подходящим интерфейсом пользователя, таким как графический пользовательский интерфейс, основанным на Web интерфейсом, основанным на тексте интерфейсом или интерфейсом командной строки, помимо прочих. Интерфейс 410 пользователя подсоединен к уровню 420 правил и модулю 430 программирования для конечного пользователя. Уровень 420 правил может включать в себя все заранее определенные компоненты системы EUP, включая созданные конечным пользователем агенты, пакеты и другие компоненты.
Модуль 430 программирования (для) конечного пользователя обеспечивает механизм, посредством которого конечный пользователь может определять компоненты, такие как агенты. Модуль 430 программирования конечного пользователя наряду с интерфейсом 420 пользователя может обеспечивать многие, если не все, функциональные возможности, которые интегрированная среда разработки может предоставить разработчику традиционных программ. Такие функции могут включать в себя способность повторно использовать компоненты, обновлять компоненты, формировать компоненты с помощью инструмента перетаскивания (drug-and-drop) графических "штучек" или посредством действий по сценарию, помимо других подходов.
Уровень 440 файловой системы может обеспечивать концептуальное представление того, как элементы данных сохранены на некоторой физической среде, такой как жесткий диск или оптический диск, помимо других. В этом конкретном примере представлена файловая система, которая выглядит тяжело на концепциях объектно-ориентированной с