TGViewer
Записки системного архитектора Записки системного архитектора @sysarchthoughts · 269 subscribers
Post #156 348
про #моделирование

Я проповедую подход под названием Model Based System Engineering (MBSE) в применении к созданию программных систем. Изначально этот подход создавался для физических инженерных систем, но сами принципы вполне применимы в ИТ.

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

В инкрементальном процессе разработки у нас всегда есть какое-то актуальное состояние {модель + система}, и есть поток инкрементальных изменений модели и соответствующих изменених системы.

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

Важные моменты:
1. Глубина детализации моделей и технология их создания, поддержания и модификации должны быть достаточно легковесными, чтобы не превратить модели в обузу. Модель должна позволять до разработки быстро прогонять множество итераций обсуждения, верификации и модификации.
2. Способ представления моделей должен быть понятен заказчикам, разработчикам, тестировщикам и т.п., чтобы обсуждения и уточнения моделей были конструктивными.
3. Технология ведения моделями должна позволять представлять в виде отдельного читаемого артефакта инкрементальные изменения модели - это позволяет отказаться от ТЗ. На стадии анализа и проектирования очередного инкремента достаточно внести и согласовать в команде изменения в модель исходной системы, и артефакт, представляющий это изменение становится почти готовой постановкой на реализацию, останется лишь для полноты картины приложить к нему описание мотивации изменений.

Если на старте проекта договориться о составе и формате представления моделей, то дальше процесс становится почти прозрачным, с минимумом писанины. Звучит красиво, вопрос в том, какая же технология представления моделей позволяет работать таким образом. Удивительно, но пока что самый удобный и лаконичный способ моделирования, который удалось найти - это текстовые описания под гитом в markdown, plantuml, yaml и прочие лаконичные умеренно структурированные представления. Популярный в отрасли Confluence не удалось приспособить, он не позволяет явно управлять изменениями.
  • 👍 3
  • 🤔 2
More from @sysarchthoughts
  1. Aug 4, 2026Мне жена как-то сказала, что только в зрелом возрасте осознала трагедию сказки о рыбаке и…
  2. Jul 2, 2026Я не давлю. Я пытаюсь опереться.
  3. Apr 2, 2026Пригласили меня тут в жюри школьного проектного конкурса, и вот что хочу сказать: мало кто…
  4. Mar 22, 2026Как технические границы делают все бизнес-критичным? Ключевой вопрос, которому посвящена э…
  5. Mar 22, 2026Неуловимо напоминает "основной закон органической химии". Если смешать бочку мёда и бочку…
  6. Mar 10, 2026(продолжение рассуждений про больницу) Что мне тут понравилось, что беру на заметку. 1. Че…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →