1. Предисловие. Вопль к создателям
Мы не пишем программ, или почти не пишем. Мы живем за чужой счет. Мы — паразиты. Вы, наши дорогие коллеги, в тиши кабинетов, попутно печатаясь и защищаясь, создаете один из видов национального продукта — программное обеспечение. Мы же не создаем национальный продукт. Мы лишь пытаемся его хоть как-то использовать в тех вычислительных центрах, в которых мы работаем. Спору нет, вы научились делать надежное программное обеспечение, и мы знаем, чего вам это стоило. Мы, ведь, тоже читаем книги по технологиям программирования, хотя, значительно реже их пишем. Надежное программное обеспечение, то есть соответствующее документации — это уже хорошо. Hо нам этого мало. Этого достаточно там, где нас нет, например, на Луне, там, где программное обеспечение все делает "само", без участия человека. Надежное программирование — панацея от всех бед и там, где программное обеспечение работает независимо от предыстории (трансляторы, библиотеки стандартных программ), то есть, оно не создает и не поддерживает какие-то жизненно важные файлы. Там же, где программное обеспечение включено в одну систему обработки данных (сод) вместе с человеком, там, где поведение системы зависит от предыстории (операционные системы, банки данных, АСУ, например) там надежного программирования оказывается мало. Там уже нужна живучесть и жизнеспособность всей системы обработки данных, что, увы, выходит за рамки традиционного системного программирования. В последнее время вы всерьез занялись анализом качества программ и даже больших программных комплексов [1,8]. Hо если говорить о системах, которые я называю СОД, то этот анализ затрагивает в основном разработчиков ПО, пользователей ПО и тех, кто сопровождает ПО СОД. Вопросы же обслуживания не ПО, а всей СОД, как единого целого, остаются все еще без внимания. Потому-то мы и существуем, парасистемные программисты, приставленные денщиками то к генератору ввода, то к операционной системе, то к системе управления базами данных (СУБД), а то еще и к какой-нибудь АСУ "зарплата" или "подготовка кадров". Чаще всего одна такая система одним денщиком не обходится, а систем этих — великое множество. Hа каждом ВЦ они завязаны в иерархические системы. Hа нижнем их уровне находятся, как правило, операционные системы со своим обслуживающим персоналом и пользователями. Затем, выше, идут СУБД и системы, вроде "Rамы", "PPB", "JEC" и т. п. Со своим обслуживающим персоналом и пользователями. За ними идут всевозможные АСУ и сапр, естественно, со своими пользователями, а главное, с обслуживающим их персоналом. В общем, до безработицы нам, парасистемным программистам далеко. Вот такие системы, как правило, с участием людей (обслуживающего персонала и пользователей самой разной квалификации), допускающие, в основном, перерывы в функционировании на ремонт и восстановительные работы, но абсолютно не допускающие утери текущего состояния (в том числе, файлов или баз данных) я и хочу проанализировать. Проанализировать с точки зрения их жизнеспособности, с точки зрения их, если хотите, угодливости и понятливости, выносливости и живучести, честности и верности. Вы уже поняли, чего я хочу. Я хочу, что бы не я был лакеем при программном обеспечении системы обработки данных, а оно было лакеем при пользователе этой СОД. Как вы уже догадались из названия, этот анализ не претендует на научность. Он лишь представляет собой попытку на отдельных этюдах из жизни парасистемных программистов поставить проблемы. Решать же эти проблемы придется вам, решать настоящими, системными методами.
Как известно, первый кризис программного обеспечения (по) был связан с ненадежностью программ, причем, источником ненадежности являлись ошибки кодирования программ. Благодаря появлению дисциплин и даже технологии программирования наступил некоторый перелом на этом этапе борьбы человека со стихией. Hо несмотря на повышение надежности ПО (в смысле адекватности кодирования), человекомашинные системы обработки данных внедряются очень медленно. Более того, уже создано большое количество СОД и продолжается создание новых систем, которые никогда внедрены не будут. Сидя у очередного разбитого корыта, изготовители таких систем обвиняют во всех бедах, как правило, внешнюю по отношению к их системе среду, начиная от пользователей системы, которые "сами не знают, чего хотят", и кончая низкой квалификацией и дефицитностью обслуживающего сод персонала. Между тем, создатели СОД, знают они это или нет, являются прежде всего математиками. Если на проблему посмотреть с этой точки зрения, то вышеприведенные оправдания, это оправдания математика, который для исследования некоторого явления природы выбрал неадекватную модель и теперь ее, эту модель, пытается в чем-то обвинять. Да, каждая программа, входящая в программное обеспечение СОД (ПО СОД) может соответствовать своему описанию и не содержать ни одной ошибки, но всю систему это не спасет, если математическая модель той среды, в которой по СОД должно функционировать, плоха. Попробуем же проанализировать подобного рода ошибки с целью найти закономерности в их возникновении, и попробуем сформулировать требования к СОД, которые позволят ей освободиться от указанных выше недостатков. Попробуем, также, дать рекомендации пользователям СОД, как по внешним признакам оценить СОД с точки зрения внедряемости. Итак, первый кризис программного обеспечения родил технологию программирования, второй кризис программного обеспечения, являющийся частью кризиса идеологии систем обработки данных, должен родить новую идеологию, а точнее, технологию систем обработки данных [2]. Рассматриваемые проблемы могут показаться несущественными тем, кто чуть ли не единолично пользуется и сам же обслуживает собственую СОД (например, собственный файл с исходными текстами). Другое дело, когда несколько десятков людей в вцкп круглосуточно эксплуатируют СОД, результатами работы которой пользуются другие несколько десятков, а то и сотен людей, не имеющих понятия о принципах работы вцкп, в то время, как третий коллектив перманентно изменяет программное обеспечение и документацию этой СОД. Тогда уже методы и средства организации работы такой СОД выходят за рамки отдельных программ и даже ППП. Здесь впору задуматься архитекторам вычислительных систем. Приведенные ниже примеры, если это не оговорено особо, относятся прежде всего к ПО, разработанному в рамках операционной системы ОС ЕС ЭВМ, однако, они не загромождены спецификой этой ОС, а выводимые закономерности носят общий характер.
