Post #929

Вы удивитесь, но статья Raccoon, L.B.S. (1995) The Chaos Model and the Chaos Life Cycle, ACM SIGSOFT Software Engineering Notes, 20, 1 из первоапрельского поста на самом деле существует! Про неё даже в Википедии написано. L.B.S. — это сокращение от Laughing But Serious, по-русски что-то вроде "смех смехом, но серьезно"). Raccoon, я думаю, понятно. Так вот что пишет этот енот: каждая строка кода соответствует всему проекту. Поэтому методика скорее не про хаос, а про фракталы, т.к. на каждом уровне повторяется один и тот же цикл работ. У нас есть 4 уровня: * вся система, * отдельный компонент архитектуры, * отдельная функция * отдельная строка кода. Все уровни связаны между собой. Смежные уровни влияют друг на друга очень сильно, отдаленные — слабо. Но тут как раз и возникает связь с теорией хаоса в математическом смысле, когда минимальные изменения (одна строка кода) приводят к принципиально разным — и непредсказуемым — результатам в макро-масштабе. То есть система находится в очень далеком от стабильного состоянии. Собственно, стабилизация системы на каждом уровне — это и есть конечная цель. Линейные модели, согласно автору, рассматривают систему, как стабильную, до возникновения новой задачи. После успешной реализации задачи (пройдя стадии определения проблемы, разработки решения и интеграции его в существующую систему) достигается новое стабильное состояние. В хаотической модели система ни в какой момент не находится в стабильном состоянии, а стадии фрактально отражаются на каждом уровне. В линейной модели сначала вы определяете проблему на уровне всей системы ("собираете требования"), потом "декомпозируете" её на более низкие уровни, дожидаетесь решения и проверяете его. В хаотической — определяете проблему на уровне системы, декомпозируете на низкие уровни, сталкиваетесь там с новыми проблемами, определяете их (вероятно, уже не в терминах требований, а в большей степени в виде сочетания требований и ограничений), пытаетесь решать, переходите на более низкий уровень, сталкиваетесь там с новыми проблемами, и так далее, вплоть до отдельной строки кода. А потом в обратную сторону — реализовать, проверить, интегрировать, проверить систему после интеграции. Разработчик при этом находится между двух огней, они как раз видны на картинке: внешние требования к системе (требования пользователей и ограничения) сверху и возможности архитектуры/инструментов снизу. И вот где-то между ними, в попытке придумать решение с учетом и того, и другого, и находится большая часть работы. При этом, как отмечает автор, для такой работы нет инструментов. Нижний уровень описывается интерфейсами библиотек и классов, верхний — сценариями использования, UI и внешними API. Их связка не описывается и не моделируется ничем (на 1995 год). 30 лет спустя мы называем это "архитектурой приложений" и "дизайном системы", но сильно легче, честно говоря, не стало. Интересно, что разработчик идёт в эту историю один, без сопровождения. Аналитик может проработать определение проблемы на верхнем уровне, выявить проблемы, с которыми столкнется пользователь или смежная системы. А вот с какими проблемами столкнется разработчик, пытаясь это реализовать внутри, аналитик обычно даже не представляет. Но разработчику придется делать то же самое — анализировать требования и ограничения, вырабатывать решение, реализовывать и проверять его. Поэтому разработчики часто скептически смотрят на аналитиков — ну да, мы это всё каждый день делаем, только не называем громкими словами. А ещё у нас всё детерминировано, хорошо бы на входе тоже все было определено, а не эти непонятные люди, которые сами не знают, чего хотят. Ну и поэтому решение всегда влияет на дизайн, причем очень часто заранее непредсказуемым образом — ведь о проблемах и ограничениях низкого уровня мы узнаем, только когда начнем пытаться это делать. И влияние движется не только сверху вниз, но и снизу вверх — ограничения решения могут заставить пользователей перестроить свою деятельность. Впрочем, неожиданные возможности тоже — риски бывают и положительными.