Письмо 05 - Формальное описание предметной области

Говоря о сложных программных системах, подразумевается то, что предметные области, которые они моделируют, также сложны. Мало сказать, что сложная программная система содержит в себе большой объём кода. Это не основа сложности. Если бы объём кода служил главным критерием оценки сложности системы, то тогда было бы непонятно, почему нельзя прямо экстраполировать время, потраченное на написание, скажем, 1000 строк, на время, которое потребуется для создания системы в 1000000 строк кода. Было бы слишком наивным предполагать, что во втором случае потребуется в 1000 раз больше времени. Фредерик Брукс приводит в своей книге «Мифический человеко-месяц или как создаются программные системы» убедительное доказательство того, что такой простой линейной зависимости не существует. В частности, он отмечает, что чем выше зависимости между различными группами разработчиков, тем сложнее выполнить координацию их действий, а, следовательно, тем больше требуется времени и финансовых ресурсов для работы над проектом. Это объясняет и тот феномен, что простое увеличение количества людей занятых в создании системы может не только не сократить сроки разработки, но и, наоборот, увеличить их.

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

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

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

Но, не смотря на это, сложные, по современным меркам, системы всё-таки создаются. Как же это происходит? Именно так и происходит. Единожды созданная система с присущими ей огрублениями постоянно дорабатывается и совершенствуется за счёт выпуска новых версий. Соответственно, разработчики этой системы становятся её пожизненными «рабами». Интересен и сам процесс разработки таких сложных систем. Разработчики вынуждены строго координировать свои действия, постоянно собирать и тестировать систему, вести журналы изменений и дополнений, отслеживать версии каждой составляющей и т.д. и т.п. Понятно, что административный контроль при такой организации работ имеет первостепенное значение, что, к сожалению, приводит к утрате творческого начала и при этом не даёт требуемого качества. Сегодня уже никого не удивишь тем, что в тестировании той или иной системы принимают участие сотни тысяч программистов, администраторов и менеджеров, а количество зафиксированных ошибок занимает несколько томов. Если это не крах метода нисходящего проектирования, тогда что это?

Сайт Alexus Software Development