Как выстраивается архитектура приложения интернета вещей

Updated: Jun 21, 2018

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


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


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


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


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


Если пользоваться «театральной метафорой», то в идеальном случае разработчик архитекторы получает от «автора пьесы» (разработчика концепции или технического задания - в зависимости от принятой методологии разработки) список действующих лиц (спецификацию объектов) и сценарий (use case).

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


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


1. Определяем перечень объектов, участвующих в решении проблемы;

  • Задаем их идентификаторы

  • Определяем ключевые свойства

2. Определяем сценарий действий каждого объекта, необходимых для решения проблемы;

  • Определяем какие свойства объекта изменяются при каких условиях

  • Определяем информационные взаимодействия, обеспечивающие скоординированные действия объектов по своим сценариям;

  • Определяем, какие события или предупреждения обеспечивают взаимодействия объектов

  • Определяем, изменение каких свойств объектов, либо результат каких взаимодействий являются источниками событий или предупреждений

3. Определяем, какие из этих взаимодействий будет обеспечиваться приложением, а какие нет;

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


4. Определяем интерфейсы взаимодействия объектов с приложением (как правило это UI для пользователей, API - для виртуальных объектов, датчики - для физических);

  • Задаем идентификаторы и свойства интерфейсов, если необходимо

  • Определяем процедуры обработки данных, если необходимы

  • Определяем источники событий и предупреждений, если присутствуют

5. Определяем средства коммуникации объектов с приложением;


6. Определяем «двойники», являющиеся информационными моделями объектов;

  • Задаем их идентификаторы

  • Задаем ключевые свойства

  • Задаем процедуры (сервисы)

  • Задаем на какие события и предупреждения реагирует двойники (подписки) и то, как именно (процедуры в рамках подписок)

7. Создаем обеспечивающую систему - ее объекты и служебные функции;

  • Задаем идентификаторы объектов

  • Задаем ключевые свойства объектов

  • Задаем процедуры (сервисы)

  • Задаем на какие события и предупреждения реагируют объекты (подписки) и то, как именно (процедуры в рамках подписок)

Покажем, как создается архитектура приложения на простом примере. Вот упрощенная архитектура приложения интернета вещей в общем виде:

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

Для этого система должна:

  • располагать информацией о расположении аудиторий,

  • "знать" о расписании конкретного посетителя,

  • уметь идентифицировать посетителя и определить его текущее местонахождение,

  • уметь выделить из расписания конкретное мероприятие, определить место его проведения, построить рекомендуемую траекторию движения по территории,

  • представить всю это информацию в виде веб-страницы, доступной для просмотра на смартфоне, или же в виде дополненной реальности.

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



Вот небольшие видео с разбором такой задачи на практикуме в Британской высшей школе дизайна: