Проектирование динамики

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

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

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

В простых случаях классическая модель прекрасно работает и необходимая динамика может представляться через справочники статусов (состояний) и полей дат. Например, заказ товара может иметь поле статуса, а также даты создания, оплаты, отгрузки и оплаты.

В таком случае динамика в самой схеме данных не очевидна и имеет жесткую реализацию через алгоритмы.

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

1. От простого к сложному

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

Рассмотрим пример функционального решения, в котором в зависимости от заданной границы реализации явно проектируются сущности для представления динамики: мониторинг физиологического состояния человека.

1.1. Состояния и изменения

В самом простом случае мы определяем показатели и интервал их записи: например, температура тела, пульс (+ритм) и давление каждые полчаса. Таким образом, мы получаем состояние человека в определенные периоды времени как набор показателей.

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

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

indicators

Рисунок 1. Количественное измерение состояния/изменений.

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

vertical-partitioning

Рисунок 2. Вертикальное секционирование данных: разделение постоянных атрибутов сущности и атрибутов ее состояний.

1.2. События

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

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

events

Рисунок 3. Cобытия как качественное измерение для анализа факторов и их результатов.

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

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

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

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

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

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

environments

Рисунок 4. Определение внешних факторов.

1.3. Структура и циклы

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

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

structure

Рисунок 5. Структурная декомпозиция.

Функциональная декомпозиция является сложной задачей и требует глубокого изучения предметной области. Логически динамика основана на циклах (повторяемость) и функциях (взаимодействии и зависимости).

Можно использовать техники анализа конечный автомат или диаграмма состояний (state machine) из UML.

cycles

Рисунок 6. Функциональная декомпозиция: качественное измерение состояний.

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

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

2. Процессы

Шаблон проектирования процессов используется для проектирования пользовательского интерфейса или функциональности для приложений среднего и высокого уровня сложности.

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

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

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

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

dd-process

Рисунок 7. Базовая структура процесса.

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

dd-process-events

Рисунок 8. Объединение процессов с изменениями (показателями) и событиями.

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

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

Полная реализация процессов требует также решения задач по интеграции, поскольку является сквозным решением для разных подразделений и приложений. Имеется множество разных подходов и платформ для интеграции данных и приложений на основе управления процессами (ESB, BPM, SOA) и нотаций для их формализованного описания и моделирования (IDEF0, UML, BPMN).

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

3. Первичность динамики

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

Если последовательно выполняется несколько проектов в схожих областях, например, в логистике (торговля, производство, транспорт), то при обобщении решений может получиться интересный эффект:

  • Упрощение логики за счет получения полной группы функций – глубина и целостность понимания предметной области
  • Динамические сущности становятся первичными и обеспечивают универсальное множество операций.

dd-streams

Рисунок 9. Логистика: ресурсные потоки и узлы.

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

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