Меню


Site Logo

Архитектура

Принципы

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

Виды модулей

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

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

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

Модуль-библитека. Модуль-библиотека оборачивает функции API операционной системы или сторонние библиотеки и предоставляет доступ к ним посредством протокола. Обычно модуль-библиотека имеет простой автомат в форме «ромашки», так как реализует атомарные независимые действия. Если для решения задачи требуется реализовать более сложное поведение, то над модулем библиотекой строится модуль логики.

Составное приложение

Схема. Конечный продукт определяется сочетанием модулей, входящих в него, и настройкой их взаимного поведения. Это задаётся схемой.

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

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

Составное приложение

Схемы описываются декларативно на языке M.

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