На этом шаге рассмотрим понятие и причины сложности систем программного обеспечения.
Как известно, не все системы программного обеспечения являются сложными. Существует класс приложений, проектируемых, разрабатываемых, сопровождаемых и используемых одним и тем же человеком, — либо начинающим программистом, либо профессионалом, работающим в одиночку. Такие системы имеют очень ограниченную область применения и очень недолго используются. Как правило, их проще заменить новыми программами, чем пытаться повторно использовать, переделывать или совершенствовать.
В области разработки промышленного программного обеспечения можно найти программы, демонстрирующие самые разные виды поведения, например, системы с обратной связью, которые управляют или управляются событиями физического мира; программы, поддерживающие целостность баз данных, содержащих сотни тысяч записей; системы управления и контроля за реальными объектами. Такие системы используются долго, и со временем от их нормального функционирования начинают зависеть многие пользователи.
В отрасли промышленного программирования также существуют средства, упрощающие создание приложений в конкретных предметных областях, а также программы, имитирующие некоторые аспекты человеческого интеллекта. Важнейшей особенностью промышленной программы является ее высокая сложность.
Это свойство является существенной характеристикой всех крупных систем программного обеспечения. Сложность программного обеспечения объясняется четырьмя причинами:
- Сложность предметной области.
Пытаясь решить проблемы с помощью программного обеспечения, мы неизбежно сталкиваемся с необходимостью удовлетворить множество различных, иногда взаимоисключающих требований.
Пользователи и разработчики часто по-разному видят сущность проблемы и предлагают разные способы ее решения. Даже если пользователь точно знает, что ему нужно, его требования очень трудно формализовать.
Требования, предъявляемые к системе программного обеспечения, в процессе разработки часто изменяются. Это еще больше повышает ее сложность. Как правило, техническое задание корректируется из-за того, что в процессе проектирования системы постановка задачи постепенно уточняется.
Системы со временем эволюционируют, по плану или спонтанно. Иногда этот процесс по ошибке называют сопровождением программного обеспечения. Точнее говоря, сопровождением (maintenance) называется исправление выявленных ошибок, эволюцией (evolution) - реакция на изменение технических требований, а сохранением (preservation) - попытка всеми возможными средствами продлить функционирование устаревших и распадающихся частей программного обеспечения. Как показывает опыт, значительная доля ресурсов, выделенных на разработку программных систем, тратится именно на сохранение.
- Трудности управления проектированием.
Основная задача разработчиков программного обеспечения — создать иллюзию простоты, чтобы защитить пользователей от огромной и часто произвольной сложности проекта.
Для уменьшения размеров программ изобретаются методы, создающие иллюзию простоты и позволяющие повторно использовать существующие коды и проектные решения. Тем не менее требования, предъявляемые к системе, часто вынуждают проектировщиков либо создавать заново большое количество программ, либо использовать существующий код, адаптируя его к новым условиям.
Ни один человек никогда не сможет полностью понять сложную систему. Даже если разложить ее на составные части, придется анализировать сотни, а иногда и тысячи отдельных модулей. Такой объем работ под силу лишь команде разработчиков, состав которой в идеале должен быть минимальным. Независимо от количества разработчиков, перед ними постоянно возникают сложные проблемы, связанные с коллективным проектированием. Чем больше разработчиков, тем сложнее связи между ними и тем труднее координировать их взаимодействие, особенно если участники работ географически удалены друг от друга, что происходит довольно часто. Таким образом, при коллективной разработке программного обеспечения главной задачей руководства является обеспечение единства и целостности проекта.
- Необходимость обеспечить гибкость программ.
Программирование обладает предельной гибкостью и позволяет проектировщику выражать абстракции любого уровня. Эта гибкость весьма привлекательна, поскольку она побуждает разработчика самостоятельно создавать практически все базовые конструкции, из которых состоят абстракции более высоких уровней.
- Сложность описания дискретных систем.
Внутри крупного приложения могут существовать сотни и даже тысячи переменных, а также несколько потоков управления. Состояние прикладной программы в каждый момент времени описывается совокупностью всех переменных, их текущих значений, адресов и стеков вызова для каждого процесса. Так как программа выполняется на цифровых компьютерах, возникает система с дискретными состояниями. Дискретные системы имеют конечное число возможных состояний. В крупных системах наблюдается так называемый комбинаторный взрыв, делающий это число очень большим.
Проектируя системы, разработчики, как правило, разделяют их на компоненты так, чтобы одна часть как можно меньше влияла на другую. Однако переходы между дискретными состояниями невозможно моделировать с помощью непрерывных функций.
Каждое событие, внешнее по отношению к системе, может перевести ее в новое состояние, и, более того, переход из одного состояния в другое не всегда является детерминированным. В худшем случае внешнее событие может повредить систему из-за того, что ее создатели не предусмотрели все возможные варианты. В дискретных системах любое внешнее событие может повлиять на любую часть внутреннего состояния системы.
Это является основным стимулом для интенсивного тестирования систем программного обеспечения. Тем не менее, за исключением самых простых систем, исчерпывающее тестирование провести невозможно. В настоящее время нет ни математических инструментов, ни интеллектуальных возможностей для полноценного моделирования поведения больших дискретных систем. Следовательно, мы должны удовлетвориться приемлемым уровнем уверенности в их правильной работе.
На следующем шаге рассмотрим признаки сложной системы.
