Язык контекстного программирования с несколькими интерфейсами

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

Несколько инфраструктур были описаны, независимо друг от друга, и разработаны по-разному, но при этом связаны друг с другом.

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

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

Чистая архитектура для программного обеспечения

«Чистая архитектура». Программа переводит работу действия с объектами, представляющими бизнес, но она не зависит от фреймворков, пользовательского интерфейса, баз данных. Каждый из них является взаимозаменяемым, один интерфейс - другим, один менеджер базы данных - другим.
Программу можно протестировать с помощью тестового интерфейса.

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

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

Шестиугольная архитектура

Или «Шестиугольная архитектура». У нее тоже есть концентрические фигуры, но здесь это шестиугольники. Центральный шестиугольник - это приложение. Он включен во второй, который является набором адаптеров. Как и в предыдущем случае, они готовят данные для передачи в обоих направлениях между приложением и внешними инструментами. Это фреймворки, базы данных, пользовательский интерфейс.
Она также планирует иметь специальный интерфейс для тестовых пакетных сценариев, они связаны с приложением определенным адаптером, в то время как пользовательский интерфейс также имеет свой адаптер.
Понятие шестиугольника имеет связь с реализацией инфраструктуры. Каждая грань соответствует порту. Порт имеет протокол для связи с типом агента. Адаптеры имеют порт для связи с базой данных, порт для интерфейса. Центральная программа имеет порты для связи с каждым адаптером.
Шестиугольная фигура на самом деле символична. Количество граней зависит от количества портов, их не обязательно 8, это принципиальная фигура.

Заложив портовый принцип, мы приблизились к реализации. Порт может быть методом объекта, и объект имеет методы для каждого порта.

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

С шестиугольной архитектурой остается использовать классические языки программирования. Но с архитектурой PCI все может измениться.

PCI, контекстное взаимодействие данных

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

PCI можно рассматривать как дополнение к Model View Control (Модель вид-контроллер), это на самом деле одно и то же лицо, Trygve Reenskaug считается изобретателем обеих моделей.

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

А действие, динамика системы? Действие представлено ролями.
По мнению разработчика ИНН, если понятие ролей не было принято в программировании (в отличие от MVC-модели), то это потому, что языки ориентированы на классы, а не на объекты. (Ref: Trygver). Классы описывают концептуальные модели и их свойства, но не фиксируют их взаимодействия и возникающую в результате сложную систему. Они могли бы осуществляться путем обмена сообщениями, которые будут определяться вкладом в достижение той или иной цели, и вкладом, соответствующим контексту.

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

Он основан на UML, модели, которая определяет себя так: программа = структуры данных + алгоритмы + связь.

Данные представлены объектами, но программист также описывает связь между этими объектами. Наконец, алгоритмы - это обработка данных, полученных в результате запросов.

Один из интересных аспектов системы Ренскауга - в этом предложении:

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

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

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

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

Дени Суро 4 января 2014 года.