Моделирование отношений

Моделирование отношений

Иллюстрации

Показать все

Реферат

Перекрестная ссылка на родственные заявки

Эта заявка испрашивает преимущество предварительной заявки 60/654,237 на выдачу патента США, зарегистрированной 18 февраля 2005 г. и озаглавленной «OBJECT ORIENTED RELATIONSHIP MODELING» («Объектно-ориентированное моделирование отношений»). Все содержание этой предварительной заявки включено в материалы настоящей заявки посредством ссылки.

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

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

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

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

Раскрытие изобретения

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

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

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

При этом прием выражения отношения может содержать этап, на котором принимают отношение между типами в нотации свойства.

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

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

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

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

Фиг. 1 - структурная схема системы отношений.

Фиг. 2 - структурная схема примерной системы отношений.

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

Фиг. 4 - структурная схема системы компиляции.

Фиг. 5 - структурная схема интерфейсной системы для содействия взаимодействию с данными.

Фиг. 6 - структурная схема интегрированной системы или среды разработки.

Фиг. 7 - блок-схема алгоритма способа определения отношений.

Фиг. 8 - блок-схема алгоритма способа компиляции.

Фиг. 9 - блок-схема алгоритма способа информационного взаимодействия.

Фиг. 10 - блок-схема алгоритма способа содействия разработке программы.

Фиг. 11 - схематическая структурная схема примерной среды компиляции.

Фиг. 12 - схематическая структурная схема, иллюстрирующая подходящую рабочую среду.

Фиг. 13 - схематическая структурная схема примерной вычислительной среды.

Осуществление изобретения

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

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

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

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

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

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

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

Фиг. 2 иллюстрирует примерную систему 200 взаимодействия отношений. Система 200 предусмотрена, чтобы облегчить описание и обсуждение аспектов нововведения предмета изобретения. Система 200 включает в себя один или более методов 210 отношений и два элемента А 220 и В 230. Изображенные графически как есть отношения между элементом А 220 и элементом В 230 не определены в пределах или в качестве свойств этих элементов. Скорее отношение определено внешним по отношению к элементам в качестве первоклассного понятия. Методы 210 отношений инкапсулируют вычисление для взаимодействия с элементами и составными частями элементов.

В качестве примера, а не ограничения, рассмотрим объект для сценария реляционного преобразования. В частности, эта ситуация является одной из тех, в которой является желательным программировать в зависимости от связей базы данных с объектами. Таблица базы данных, на понятийном уровне содержащая объекты типа Т, может быть представлена на языке программирования коллекцией типов, такой как EEnumerable<T> на С#, где Т является классом со свойствами, которые поставлены в соответствие полям таблицы. Отношение базы данных в таком случае может быть представлено на языке программирования статическим классом. Такой класс предусматривает статические методы, которые осуществляют навигацию по этим отношениям, инкапсулируя условия объединения. Например, элемент А 220 может быть объектом, типом или классом, который соответствует таблице заказчиков, а элемент В 230 может быть объектом, типом или классом, который соответствует таблице заказов. Например:

public class Customer {...}

public class Order {...}

Отношения 210 могут быть определены отдельно от элементов А 210 и В 220 в программных логических структурах, таких как статический класс, следующим образом:

public static class OrderRelationship {

public static Customer GetCustomerGivenOrder(Order order);

public static IEnumerable<Order> GetOrdersGivenCustomer

(Customer, customer);

public static IEnumerable<Customer> GetCustomersGivenOrders

(EBnurnerable<Order> orders);

public static IEnumerable<Order> GetOrdersGivenCustomers

(TEnumerable<Customer> customers);

}

Здесь методы класса обеспечивают механизм для осуществления навигации по хранилищу данных в соответствии с большим количеством отношений, которые могут существовать между заказчиками и заказами. Здесь бинарные отношения инкапсулированы классом и методами класса. Бинарные отношения могут включать в себя связи типа «один к одному», «один к многим», «многие к одному» и «многие ко многим». Первый метод «GetCustomerGivenOrder» («Получить заказчика заданного заказом») фиксирует отношение «один к одному», в котором заказчик отыскивается по данному конкретному заказу. Второй метод «GetOrdersGivenCustomer» («Получить заказы, заданные заказчиком») является отношением «многие к одному». Здесь отыскивается большое количество заказов, ассоциативно связанных с конкретным заказчиком. Третий и четвертый методы «GetCustomersGivenOrders» («Получить заказчиков, заданных заказами») и «GetOrdersGivenCustomers» («Получить заказы, заданные заказчиками») - «многие к многим». В частности, первый метод извлекает совокупность заказчиков, ассоциативно связанных с указанными заказами. По данному набору заказов четвертый метод может найти связанных заказчиков.

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

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

Таблица 1
Идентификатор	Тема	Участники
1	Привет!	Идентификатор	Электронный адрес
1	Джили
2	Майкл
2	Ау!	Идентификатор	Электронный адрес
3	Джили
4	Бен

Согласно отношению ассоциации есть несколько разных типов, в том числе ссылка, общее значение, условие и сущность. Ассоциация ссылки может соответствовать отношению первичного ключа внешнего ключа. Следующий пример изображает отношение ассоциации ссылки «Заказчик-Заказ», где таблица 2 соответствует заказчикам, а таблица 3 - заказам:

Таблица 2
Идентификатор	Имя
1	Фред
2	Вильма

Таблица 3
Идентификатор	Заказчик	...
1	(1)	...
2	(2)	...
3	(1)	...

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

Таблица 4
Идентификатор	Имя	Инструмент
1	Фред	Пианино
2	Джон	Гитара
3	Вильма	Пианино

Таблица 5
Идентификатор	Наименование
1	Гитара
2	Флейта
3	Пианино

Ассоциация условия является отношением, выраженным запросным критерием. Следующий пример предусматривает ассоциацию условия контактного документа (таблицы 6,7):

Таблица 6
Идентификатор	Адрес электронной почты
1	Элемент 0: benja@xyz.comЭлемент 1: mbtyalor@xyz.com
2	Элемент 0: jili@xyz.com

Таблица 7
Идентификатор	Автор
1	mbtyalor@xyz.com
2	jili@xyz.com
3	benja@xyz.com

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

Таблица 8
Идентификатор	Дата найма	Идентификаторнаемного работника	Идентификаторработодателя
1	01/01/01	2	1
2	01/01/02	2	2
3	01/01/03	1	2

Таблица 9
Идентификатор	Имя
1	Фред
2	Вильма
3	Барни

Таблица 10
Идентификатор	Наименование
1	Zoo
2	Boo

Фиг. 3 иллюстрирует систему 300 отношений в соответствии с аспектом «связанного» изобретения. Подобно системе 100 по фиг. 1 система 300 включает в себя компонент 110 приемника элемента и компонент 120 формирования отношений. Как описано ранее, компонент 110 приемника может принимать и/или извлекать большое количество составных частей, таких как объекты данных, веб-страницы или XML-документы, чтобы назвать только некоторые. Компонент 120 формирования отношений может принимать и/или извлекать элементы из компонента 120 приемника. Компонент 120 формирования отношений может определять или задавать отношения или связи между элементами. Дополнительно, компонент 120 формирования может предоставлять методы или ссылки на них для извлечения конкретных элементов или их составных частей в ответ на заданное отношение. Снова подобно системе 100 система 300 может определять отношения в классе, а класс может включать в себя методы для расчета отношений. Однако система 300 также может включать в себя компонент 310 воздействия. Компонент 310 воздействия является механизмом для воздействия на именование отношений. В соответствии с аспектом нововведения предмета изобретения компонент 310 воздействия может включать в себя или быть с возможностью обмена данными присоединенным к компоненту эвристического или искусственного интеллекта, методу или механизму для логического вывода или прослеживания наименований отношений, основанных на наименованиях связанных составных частей. Например, два элемента «Customer» и «Order» могут иметь метод отношения, названный «GetCustomerGivenOrder» («Получить заказчика заданного заказом»), как в вышеприведенном примере. Дополнительно или в качестве альтернативы, компонент 310 логического вывода может содействовать компоненту 120 формирования отношений, принимая и/или предоставляя схему присваивания имен, заданной, например, посредством внешней информации метаданных.

Как было предварительно обсуждено, отношение может быть, среди прочего, бинарным отношением или общим n-арным отношением (например, центрально-лучевым отношением). Бинарное отношение может быть отношением «один к одному», «один к многим», «многие к одному» или «многие ко многим», как использовано в рассуждениях об отношении сущности. Отношение между типами S и Т может быть промоделировано статическим классом. Рассмотрим следующий пример класса, фиксирующего несколько бинарных отношений:

public static class RelationshipName_Relationship{

public static IEnumerable<T> GetTsGivenS (S,s);

public static S GetSGivenT (T t);

public static EEnumerable<S> GetSsGivenTs (IEnumerable<T> ts);

public static IEnumerable<T> GetTsGivenSs (IEnumerable<S> ss);

}

В случае отношения «один к одному» метод GetTsGivenS (Получить Т, заданные S)) возвращает единственный экземпляр Т, а в случае отношения типа «многие ко многим» метод GetSGivenT (Получить S, заданные Т) возвращает тип коллекции, такой как Enumerable (перечислимый).

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

public class Customer {...}

public class Order {...}

public static class OrderRelationship {.

public static Customer GetCustomerGivenOrder(Order order);

public static IEnumerable<Order> GetOrdersGivenCustomer

(Customer, customer);

public static IEnumerable<Customer> GetCustomerGivenOrders

(IEnumerable<Order> orders);

public static IEnumerable<Order> GetOrdersGivenCustomers

(IEnumerable<Customer> customers);

}

При условии, что переменная, которая представляет набор заказчиков в таблице заказчиков, к примеру:

IEnumerable<Customer>customers=...;

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

IEnumerable<Order>orders=

OrerRelationship.GetOrderGivenCustomer(customers).

Вызов статического метода инкапсулирует условие объединения:

SELECT (fields) FROM Customer JOIN Order ON (condition) (ВЫБРАТЬ (поля) ИЗ Заказчиков, ОБЪЕДИНЕННЫХ Заказом ПО (условию))

n-арное отношение (также указываемое ссылкой в материалах настоящей заявки как ассоциации сущности) является набором бинарных отношений, например, конкретного типа или с другими типами. Одним из примеров является отношение «центра и луча». Шаблон проектирования для такого отношения является следующим:

public static class RelationshipName_Relationship {

public static SI GetSpokelGivenHub (hub);

public static IEnumerable<Hub> GetHubsGivenSpokel (spokel);

public static S2 GetSpoke2GivenHub (hub);

public static IEnumerable<Hub> GetHubsGivenSpoke2 (spoke2);

public static EBnumerable<S 1> GetSpokelGivenHub

(IEnumerable<Hub> hubs);

public static DSnumerable<Hub> GetHubsGivenSpokel

(IEnumerable<Sl> spokel s);

public static IEnumerable<S2> GetSpoke2GivenHub

(IEnumerable<Hub> hubs);

public static IEnumerable<Hub> GetHubsGivenSpoke2

(IEnumerable<S2> spoke2s);

}

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

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

public class Person {..}

public class Organization {..}

public class Employment {..}

public static class EmploymentRelationship {

public static IEnumerable<Employment>

GetEmploymentsGivenEmployee (Person employee);

public static Person GetEmployeeGivenEmployment (Employment

employment);

public static DBnumerable<Employment>

GetEmploymentsGivenEmployer (Organization employer);

public static Organization GetEmployerGivenEmployment

(Employment employment);

public static IEnumerable<Employment>

GetEmploymentGivenEmployee(IEnumerable<Person> employees);

public static IEnumerable<Person> GetEmployeeGivenEmployment

(IEnumerable<Employment> employments);

public static IEnumerable<Employment>

GetEmploymentGivenEmployer(IEnumerable<Orgamzation>employers);

public static IEnumerable<Organization>

GetEmployerGivenEmployment

(IEnumerable<Employment> employments);

}

При условии переменной, которая представляет набор людей в таблице действующих лиц, такой как:

IEnumerable<Person>people=....

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

IEnumerable<Employment>employments=

EmploymentRelationship.GetEmploymentGivenEmployee(people).

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

IEnumerable<Organization>employers=

EmploymentRelationship.GetEmployerGivenEmployment(employments);

Последний вызов статического метода инкапсулирует условие объединения:

SELECT (fields) FROM Person JOIN Employment ON (condition) JOIN Organization ON (condition) (ВЫБРАТЬ (поля) ИЗ Действующих лиц, ОБЪЕДИНЕННЫХ Работой по найму ПО (условию), ОБЪЕДИНЕННЫХ Организацией ПО (условию)).

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

public class Person {

public IEnumerable<Employment>Employments {get;}

}

public class Organization {

public IEnumerable<Employment> Employments {get;}

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

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

Фиг. 4 иллюстрирует систему 400 компиляции, которая синтаксически унифицирует способ осуществления доступа к отношениям в соответствии с аспектом нововведения предмета изобретения. Система 400 включает в себя компонент 410 приемника выражения, компонент 420 выработки кода и компонент 430 метаданных. Компонент 410 приемника принимает программное выражение, которое включает в себя отношения между элементами, в том числе, но не в качестве ограничения, типами данных. Это программное выражение может быть упрощенным выражением, которое задано, как будто отношение является свойством. Например, при условии переменной, которая представляет набор заказчиков в таблице заказчиков: «EEnumerable<Customer>customers=...;», следующий синтаксис может быть использован, чтобы получать набор заказов, связанный с этим набором заказчиков: «IEnumerable<Order>orders=customer.Orders». Компонент формирования кода принимает это выражение и из выражения формирует более многословный код или вызов метода, такой как: «OrderRelationship.GetOrderGivenCustomers(customers)». Эти функциональные возможности задействованы компонентом 420 формирования кода через компонент 430 метаданных. Компонент 430 метаданных может извлекать или принимать метаданные по классу и предоставлять их компоненту 420 формирования кода, чтобы дать возможность преобразования из упрощенного выражения в действующее или более многословное выражение. Эти метаданные могут задавать, что «OrderRelationship.GetOrderGivenCustomers(customers)» преобразуется в «customer.Order.» В соответствии с аспектом нововведения предмета изобретения такие метаданные могут быть предусмотрены в классе, определяющем отношения между составными частями. Дополнительно, метаданные могут быть предоставлены посредством некоторого внешнего файла или схемы, которые используются системой компиляции и/или компонентом 420 формирования кода.

Обращаясь к фиг. 5, проиллюстрирована интерфейсная система 500 для облегчения информационного взаимодействия. Интерфейсная система 500 включает в себя интерфейсный компонент 510 навигации и интерфейсный компонент 520 данных, связанные с возможностью обмена данными. В качестве примера, интерфейсный компонент 520 данных может реализовать методы, которые могут быть вызваны или исполнены интерфейсным компонентом 510 навигации и наоборот. Интерфейсный компонент 510 навигации может принимать выражения отношений. Интерфейсный компонент 510 может принимать как сокращенное, так и полноразмерное выражения, такие как «customer.Orders» или «OrderRelationship.GetOrderGivenCustomers(customers)» соответственно. Там где предусмотрено сокращение, интерфейсный компонент 510 навигации может конвертировать выражение в полноразмерное выражение. Выражение затем может быть передано из интерфейсного компонента 510 навигации в интерфейсный компонент 520 данных. Интерфейсный компонент 520 данных может предоставлять выражение для выполнения над одним или более элементами. Если данные извлечены, интерфейсный компонент 520 данных может передавать результаты обратно интерфейсному компоненту 510 навигации. Таким образом, интерфейсный компонент 510 навигации и интерфейсный компонент 520 данных могут соответствовать программным интерфейсам приложения (API).

Фиг. 6 изображает интегрированную среду или систему 600 разработки в соответствии с аспектом раскрытия предмета изобретения. Система 600 может включать в себя компонент 610 редактора и компонент 620 программной поддержки. Компонентом 610 редактора является текстовый редактор, приспособленный для редактирования и/или разработки исходного компьютерного кода. В частности, компонент 610 редактора может принимать спецификацию отношений. Текстовый редактор с возможностью обмена данными присоединен к компоненту 620 программной поддержки. Компонент 620 поддержки может, среди прочего, обеспечивать программную поддержку, в том числе подсказывание, форматирование, расцвечивание, всплывающие подсказки и указание или предупреждение об ошибке. Например, в ответ на прием элемента и сигнала запуска, такого как точка, компонент 620 программной поддержки может предоставлять и/или заставлять компонент 610 текстового редактора отображать предложения для завершения оператора. Предложения могут быть сделаны касательно отношений, как представлено в материалах настоящей заявки. Например, при приеме «customer.» может быть предложено «Orders» для полного оператора «customer.Orders», указывающего, что следует быть извлеченными всем заказам для «customer». Следовательно, могут быть сделаны подсказки или предложения,