Корректность и устойчивость программных систем

Проект для лекции Lecture9.rar.

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

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

Корректность - это способность программной системы работать в строгом соответствии со своей спецификацией. Отладка и формальное или неформальное доказательство корректности создаваемого кода - процессы, направленные на достижение корректности.

Любую программу P(X, Y) с входными данными X и выходными Y можно рассматривать как функцию, преобразующую входные данные в результаты. И один из формальных способов задания спецификации задать для этой функции два предиката - предусловие Pred(X) и постусловие - Post(X, Y). Предикат Pred(X) накладывает ограничения на входные данные, а предикат Post(X, Y) задает требования к результатам работы программы. Предполагается, что программа в процессе работы не изменяет значений входных данных X. При этих предположениях корректность программы P(X, Y) можно определить следующим образом:

Программа P(X, Y) тотально корректна по отношению к предикатам Pred(X) и Post(X, Y) если для каждого входа X, для которого Pred(X) принимает значение "Истина" программа:

• Завершает свою работу;
• В момент завершения предикат постусловия Post(X, Y) принимает значение "Истина".

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

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

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

Почему так трудно создавать корректные и устойчивые программные системы? Все дело в сложности разрабатываемых систем. Когда в 60-х годах прошлого века фирмой IBM создавалась операционная система OS-360, то на ее создание потребовалось 5000 человеко-лет, и проект по сложности сравнивался с проектом высадки первого человека на Луну. Сложность нынешних сетевых операционных систем, систем управления хранилищами данных, прикладных систем программирования на порядки превосходит сложность OS-360, так что, несмотря на прогресс, достигнутый в области технологии программирования, проблемы, стоящие перед разработчиками, не стали проще. Прогресс в этой области во многом достигается за счет повторного использования кода.

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

Три закона программотехники

По аналогии с тремя законами робототехники Айзека Азимова я предлагаю три закона программотехники в том или ином виде существующие в фольклоре программистов.

Первый закон (закон для разработчика)

Корректность системы - недостижима. Каждая последняя найденная ошибка является предпоследней.

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

Второй закон (закон для пользователя)

Не бывает некорректных систем. Каждая появляющаяся ошибка при эксплуатации системы - это следствие незнания спецификации системы.

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

Более поучительна реальная ситуация, подтверждающая второй закон и рассказанная мне профессором Виталием Кауфманом, в те годы доцентом факультета ВМК МГУ - специалистом по тестированию трансляторов. В одной серьезной организации была разработана серьезная прикладная система, имеющая для них большое значение. К сожалению, при ее эксплуатации сплошь и рядом возникали ошибки, из-за которых организация вынуждена была отказаться от использования системы. Разработчики обратились к нему за помощью. Он, исследуя систему, не внес в нее ни строчки кода. Единственное, что он сделал, это описал точную спецификацию системы, благодаря чему стала возможной ее нормальная эксплуатация.

Обратите внимание на философию, характерную для этих законов: при возникновении ошибки разработчик и пользователь должны винить себя, а не кивать друг на друга. Так что часто встречающиеся фразы: "Ох уж эта фирма Чейтософт, - вечно у них ошибки!" характеризует, мягко говоря, непрофессионализм говорящего.

Третий закон (закон чечако)

Если спецификацию можно нарушить, - она будет нарушена. Новичок (чечако) способен "подвесить" любую систему.

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