Описание метода работы моей системы

Я работаю над системой дистанционного наблюдения пациентов, сигнатута ее основного метода это дистанционный мониторинг пациента, вывод информции о пациентах.

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

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

Модель finite-state machine не будет столь инфоративной, потому что она фокусируется на состояниях, а в рассматриваемом методе состояние данных не меняется, они скорее трансофрмируются. Модель workflow не выбрана из-за того, что в предметной области системы по мониторингу пациента, сама система не выполняет множество последовательных операций, а она скорее выполняет множество разных операций в среднем с 3-мя шагами.

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

Для описания через dataflow используются концепты: система, функция, входной поток данных, выходной поток данных

Функциональная модель системы:

Одна из возможных проблем, это сложность системы из-за наличия двух систем, которые обрабатывают замеры “Бэкенд” и “Мидл”, объединение этих систем сделает систему проще, но новая систему будет сложнее, хотя и не сильно. Другая система будет заниматься и валидацией и хранением замеров.

Ответ как мысли вслух, и как призыв поразмышлять вместе.

Мой ответ основан на информации из учебника СМ 11 главы, часть " Конструктивные/продуктовые описания". Если у вас “принципиальная схема”/функциональная/dataflow диаграмма, то вы у вас указываются функциональные модули(это и будет интерфейс). И раз у нас данные, какого формата(FHIR или еще что), и как он меняется после прохождения каждого интерфейса, то что указано как “замеры пациента”? Например валидация важна внутри приема замеров интерфейса, дальше просто будет передача другому интерфейсу, и данные по другому будут представлены.

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

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

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

p.p.s. Я не могу сказать, что точно понял, что вы хотели спросить.