Методический материал для разработчика ПО

Записки парасистемного программиста

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

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

Разработал Лишак Е.В. Версия 1 от 16.02.84.

1. Предисловие. Вопль к создателям.

Мы не пишем программ, или почти не пишем. Мы живем за чужой счет. Мы - паразиты. Вы, наши дорогие коллеги, в тиши кабинетов, попутно печатаясь и защищаясь, создаете один из видов национального продукта - программное обеспечение. Мы же не создаем национальный продукт. Мы лишь пытаемся его хоть как-то использовать в тех вычислительных центрах, в которых мы работаем.
Спору нет, вы научились делать надежное программное обеспечение, и мы знаем, чего вам это стоило. Мы, ведь, тоже читаем книги по технологиям программирования, хотя, значительно реже их пишем. Надежное программное обеспечение, то есть соответствующее документации - это уже хорошо. Но нам этого мало. Этого достаточно там, где нас нет, например, на Луне, там, где программное обеспечение все делает "само", без участия человека. Надежное программирование - панацея от всех бед и там, где программное обеспечение работает независимо от предыстории (трансляторы, библиотеки стандартных программ), то есть, оно не создает и не поддерживает какие-то жизненно важные файлы.

Там же, где программное обеспечение включено в одну систему обработки данных (сод) вместе с человеком, там, где поведение системы зависит от предыстории (операционные системы, банки данных, АСУ, например) там надежного программирования оказывается мало. Там уже нужна живучесть и жизнеспособность всей системы обработки данных, что, увы, выходит за рамки традиционного системного программирования.

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

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

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

2. Введение.

Как известно, первый кризис программного обеспечения (по) был связан с ненадежностью программ, причем, источником ненадежности являлись ошибки кодирования программ. Благодаря появлению дисциплин и даже технологии программирования наступил некоторый перелом на этом этапе борьбы человека со стихией. Но несмотря на повышение надежности ПО (в смысле адекватности кодирования), человекомашинные системы обработки данных внедряются очень медленно. Более того, уже создано большое количество СОД и продолжается создание новых систем, которые никогда внедрены не будут.

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

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

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

Итак, первый кризис программного обеспечения родил технологию программирования, второй кризис программного обеспечения, являющийся частью кризиса идеологии систем обработки данных, должен родить новую идеологию, а точнее, технологию систем обработки данных [2].

Рассматриваемые проблемы могут показаться несущественными тем, кто чуть ли не единолично пользуется и сам же обслуживает собственую СОД (например, собственный файл с исходными текстами). Другое дело, когда несколько десятков людей в вцкп круглосуточно эксплуатируют СОД, результатами работы которой пользуются другие несколько десятков, а то и сотен людей, не имеющих понятия о принципах работы вцкп, в то время, как третий коллектив перманентно изменяет программное обеспечение и документацию этой СОД. Тогда уже методы и средства организации работы такой СОД выходят за рамки отдельных программ и даже ППП. Здесь впору задуматься архитекторам вычислительных систем.

Приведенные ниже примеры, если это не оговорено особо, относятся прежде всего к ПО, разработанному в рамках операционной системы ОС ЕС ЭВМ, однако, они не загромождены спецификой этой ОС, а выводимые закономерности носят общий характер.

3. Железо, как оно есть.

3.1. Вера в вечную удачу.

 Разработчики некоторых систем обработки данных, видимо, работают в идеальных условиях. В тех вычислительных центрах (вц), в которых они изготавливают свои системы, никогда не бывает сбоев и отказов оборудования. Поэтому, они никогда не заглядывали в документацию по аппаратным средствам, в которой указаны те или иные вероятностные характеристики сбоев и отказов. Ну, а если какой-либо сбой все же доставит некоторую неприятность, то виноваты, конечно же, неграмотные и ленивые электронщики. Видимо, те ВЦ, где электронщики столь же плохи, просто недостойны такой замечательной системы. Ну, а в целом, дела идут хорошо. Ведь контрольный пример проходит так быстро, а выполнить правильно его нужно всего лишь один раз...

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

Примерами таких систем являются генераторы ввода [3,4], которые могут применяться лишь там, где они, в общем-то, и не нужны, там где вводится за один прием столь мало данных, что вероятность сбоя невелика.

Этюд. Ппп "Оргвыц" [6] накапливает данные о работе ВЦ в наборах данных на магнитных дисках. По мере их заполнения данные из этих наборов копируются на мл. Ппп услужливо предоставляет в распоряжение пользователя процедуру дозаписи в конец МЛ после ранее записанных во время предыдущей работы данных. При этом не предлагается ни одна процедура, которую должен выполнить пользователь после того, как эта мл, наконец, перестанет читаться или записываться во время дозаписи. Любопытно, что чем надежнее работает оборудование в ВЦ, использующем такой ППП, тем больший удар ожидает пользователя, когда сбой произойдет, и он потеряет все то, что так долго собирал.

Возможно, я необъективен по отношению к разработчикам ППП "Оргвыц". Что говорить о них, если даже в книге Дж. Мартина [7] проблемам организации баз данных посвящено 660 страниц, а проблемам, связанным с аппаратной надежностью и живучестью (целостностью) баз данных, говорится на 14 строках 45-й страницы и 8-ми строках 309-й. Десять страниц этой книги посвящены индексно-последовательным наборам данных, а о проблемах, связанных с их целостностью, не говорится ни слова.

 3.2. Сила печатного слова.

 Вот пример того, как возникают иллюзии. В документации по ОС ЕС написано, что добавление записи по ключу в индексно-последовательный набор данных равносильно для программиста добавлению этой записи на свое место в физической последовательности. Действительно, равносильно, но лишь в том случае если эта операция успешно завершилась. Более того, у меня есть подозрения, что даже и этого мало. В некоторых случаях необходимо еще, чтобы успешно завершилась операция закрытия набора данных. Если какое-то из этих условий не выполнено, то либо весь набор данных, либо некоторая его часть окажутся недоступными для последующего чтения. Если программист пишет программу, которая сама такой набор данных создает, сама его после создания корректирует, а по окончании этой программы набор уже не нужен, то программисту достаточно поверить написанному о том, как просто корректировать индексно-последовательные наборы данных. Если же такой набор данных создается для многократного использования, может быть, в течение нескольких лет после его создания, то разработчику сод, использующей этот набор данных, следовало бы знать, что такая простая с точки зрения написания программы операция, как добавление записи по ключу в индексно-последовательный набор данных представляет собой несколько операций записи в этот набор данных, разнесенных во времени и пространстве (занимаемом этим набором). Окончательная же фиксация изменений происходит по закрытию набора данных. Что прикажете делать пользователю СОД, разработчик которой по своей простоте не подумал о возможности сбоя и не предоставил пользователю никаких средств борьбы с ней? Примером может послужить все тот же ППП "Оргвыц".

Еще пример доверия к печатному слову: в паспорте на устройство вывода на перфоленту написано, что это устройство обеспечивает так мало сбоев, что на пять тысяч метров перфоленты приходится всего одна неправильная пробивка [5]. Очень трудно позавидовать пользователю СОД, разработчик которой прочел указанный документ и поверил ему. Вместо так нужной ему перфоленты он получит возможность участвовать в многочисленных склоках с обслуживающим персоналом, размахивая вышеуказанным паспортом, который в отличие от волшебной палочки перфоленту не сотворит. Возможно, что пользователь будет писать рекламации на завод-изготовитель ЭВМ, перфоратора или перфоленты. В любом случае, если только ему на самом деле нужна перфолента и он лишен садистских наклонностей, он врядли будет в большом восторге от такой СОД. Хорошо еще, если он поймет, что собака зарыта прежде всего в программном обеспечении, которое не ломается, которое не надо чинить и которое сделать надежным значительно легче, чем перфоратор.

3.3. Терновый серпантин.

 Рассмотрим последний пример подробнее, чтобы определить, как должна быть построена программа вывода перфоленты, если она должна выводить ее действительно много (по сравнению с реальной наработкой на сбой). Более того, как она должна работать, даже если сбои в среднем достаточно редки (настолько редки, что после сбоя при повторном пуске программы перфолента скорее всего не будет содержать ошибок). Для построения такой программы нужно учесть следующие соображения.

Первое. По-прежнему действует закон "чем лучше - тем хуже". Если возможность сбоя не принимается во внимание, то чем позже он произойдет, тем более потрясающий эффект он произведет среди тех, кто так верил этой системе. Поэтому, если вероятность сбоя в течение некоторого промежутка времени больше вероятности того, что ВЦ сгорит дотла (за тот же промежуток времени). То программа должна его учитывать. Прежде всего, она должна позаботиться о том, чтобы пользователь получил заведомо правильные результаты (с указанной выше вероятностью), либо не получил их вообще.

Второе. Пользователя скорее всего не устроит неполучение результатов вообще, хотя это уже лучше, чем получение возможно неправильных результатов. Хорошая программа вывода перфоленты должна либо выдать правильный результат, либо обеспечить возможность ремонта сбоящего устройства (принцип "встроенного теста"). Встроенный тест нужен тогда, когда устройство сломалось еще не настолько, что уже известно, как его чинить (нет явного отказа, а есть пакет сбоев). Действительно, допустим, что частота сбоев превысила указанную в паспорте величину на пол-порядка. "Юридически" устройство сломано (какой ценой обычно доказывается факт такой "полусломанности"!). Но если обслуживающий персонал будет вынужден его чинить, то он должен будет в течение длительного времени "гонять" на устройстве бесполезные с точки зрения пользователя тесты, занимая не только это устройство, а скорее всего, всю ЭВМ, изводя впустую уйму машинного и рабочего времени и перфоленты. Хорошо еще, если такие тесты существуют. Каждый бит драгоценной для обслуживающего персонала информации будет оплачиваться сотнями килобайт информации, бесполезной для пользователя СОД. Так пусть уж лучше вместо теста работает программа этой СОД. Тогда она, выдавая результат, заодно еще даст информацию о сбоях.

Третье. Чтобы результатом, полученным в условиях сбоя можно было пользоваться, программа должна локализовать сбой и принять меры к восстановлению корректности результата. Возможно, ведя диалог с оператором ЭВМ и разбивая всю перфоленту на контролируемые и повторяемые в случае сбоя участки. Для контроля результата она должна использовать устройство ввода перфоленты.

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

3.4. На нейтральной полосе.

Этюд. На одном ВЦ купили две ЭВМ единой системы и стали постепенно загружать их работой в пакетном режиме в среде ОС ЕС, с общим полем памяти прямого доступа на восьми дисководах (по 29 мегабайт). Сначала объем данных на устройствах прямого доступа был невелик, и сбои на дисках особенно не докучали. Но по мере наращивания объема данных работать становилось все труднее и труднее, пока ВЦ не подошел к некоторому "информационному барьеру". Стало ясно, что необходимо менять технологию настройки дисководов на взаимозаменяемость.

Электронщики, обслуживающие дисководы, заявили, что тесты проверки взаимозаменяемости у них идут. В свою очередь, системные программисты, представили богатый материал, из которого следовало, что при работе с ОС ЕС взаимозаменяемость отсутствует. Теперь, как это обычно принято в других ВЦ, можно было и подраться. Но в этом ВЦ обычно делали по-другому. Электронщики и системщики вместе стали разбираться, в чем заключается разница в подходе к взаимозаменяемости у тестового обеспечения и у ОС ЕС. Для выяснения этого вопроса системщикам пришлось отложить бесполезные в этом случае книги по управлению данными ОС ЕС и взяться за "чужие" для большинства системщиков книги по тестовому программному обеспечению и даже по аппаратуре, благо в этом благородном порыве электронщики помогали системщикам всей душой.
Обнаружилось, что электронщики пользовались следующим определением взаимозаменяемости: для любых целых I и K, не больших N, где N - количество дисководов, инициализация на I-том дисководе, запись на I-том же дисководе и чтение на K-том должны закончиться без сбоев с некоторой, близкой к единице вероятностью.

Системщики (точнее, те системщики, которые разработали ОС ЕС), понимали под взаимозаменяемостью следующее: для любых целых I, J и K, не больших N, инициализация на I-том, запись на J-том и чтение на K-том дисководах должны закончиться без сбоев с все той же, близкой к единице, вероятностью.

Итак, разница в том, что электронщики во время проверки взаимозаменяемости инициализировали пакет и записывали на него тестовые данные на одном и том же дисководе, а читали на другом. При работе же с ОС, программы управления данными, естественно, записывали данные не на тех дисководах, на которых пакет магнитных дисков инициализировался. Чтобы эта маленькая разница стала очевидной, электронщикам и системщикам пришлось выйти за границы своих знаний на нейтральную полосу. Электронщикам пришлось узнать, как работает ОС ЕС с магнитными дисками, а системщикам пришлось узнать, как выполняются канальные программы и как тестируется аппаратура.

Как только стали проверять взаимозаменяемость по-новому, выяснилось, что в этом смысле электронщикам было куда расти. Тут бы самое время высокомерно похлопать электронщиков по плечу, приговаривая, - давайте, давайте, работайте, чините ваши дисководы. Но в этом ВЦ делалось не так. Во-первых, формально электронщики не были обязаны принимать какие-то меры. Их методика проверки имела законную силу, так как она соответствовала документации по эксплуатации ЭВМ (такой документации в отрыве от документации по эксплуатации операционной системы не должно быть в принципе, нужна единая документация). Во-вторых, раз уж системщики читали книги не только по управлению данными ОС ЕС, они понимали, что достичь такой полной взаимозаменяемости электронщикам будет не под силу из-за нехватки времени, которое выделяется на профилактические работы. Шутка ли, проверить все восемь дисководов (а восемь - это так мало) на взаимозаменяемость в соответствии с вышеприведенным определением. А еще нужно учесть ограничения, которые накладывает жизнь. Это и дефицит обслуживающего персонала (электронщиков и механиков) и отсутствие запасных магнитных головок, и нестабильность питания, отсутствие хорошего заземления и т.п. (Вы, пишущие могучие трансляторы, придумывающие языки программирования и системы управления базами данных, знаете ли вы, как качество заземления влияет на работоспособность ваших детищ?).

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

Первый барьер был вызван систематическими, регулярными причинами, и они были устранены. Однако, остались случайные, несистематические причины, по которым иногда (правда, теперь уже значительно реже) записанные данные переставали уверенно читаться. Если вовремя не принимать меры, то в конце концов с томом прямого доступа будет невозможно работать. В связи с этим, системщики разбили все тома прямого доступа на категории по принципу одинаковой интенсивности записи. Для каждой категории томов были установлены свои сроки копирования со сменой оригинала. Такая "профилактика" производится все на том же "эталонном" дисководе, на котором делается инициализация томов. Теперь в этом ВЦ сбой на устройстве прямого доступа возникает не чаще, чем раз в рабочую смену.

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

Этюд. На ЭВМ М-222 (и вообще на всех ЭВМ типа М-20) магнитные ленты (МЛ) было принято дефектовать с разметкой на зоны. Для этого имелись программы разметки и дефектовки, которые тестировали поверхность мл, отбраковывая некачественные ее участки. Мне были известны несколько таких программ от официально поставляемых до "народных" (парасистемных), в которых по утверждению авторов поверхность МЛ тестируется шахматным кодом. Увы, этот код оставался шахматным разве что в оперативной памяти. Дело в том, что одна 45-разрядная ячейка памяти этой ЭВМ записывается на МЛ побайтно. В результате, "шахматная" двоичная комбинация '10101010101010...' Записывается на МЛ пятью одинаковыми и шестым "почти одинаковым" байтом! При таком "тестирующем" коде ни способность к перемагничиванию поверхности, ни чувствительность магнитных головок, ни переключательная способность оборудования не проверяется в полную силу (с максимальной частотой). Если принять во внимание еще и способ записи на МЛ (без возвращения к нулю) идеальным кодом были бы "все единички", но, учитывая систему воспроизведения и контроля данных, пришлось остановиться на "настоящем шахматном" коде.

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

3.5. Заметки по поводу.

 Следуя примеру [1], попытаемся выделить еще несколько существенных для обслуживания СОД свойств ПО.

• Неприхотливость, то есть способность ПО работать на неисправном оборудовании, пока оно не сломалось до такой степени, что неисправность легко обнаруживается и устраняется. Нужно всегда помнить, что перевести устройство из хорошего состояния в отличное на несколько порядков сложнее, чем из плохого в удовлетворительное.
• Безопасность, то есть способность при любом сбое не произвести во внешней среде необратимых изменений. Следует отличать это свойство от устойчивости. При внешнем или внутреннем возмущении устойчивое ПО будет стараться выполнить свое назначение. Например, ПО, ответственное за посадку автомата на Луну, постарается хоть криво и не туда, куда хотелось бы, но все же автомат посадить. А вот "криво" исправленная база данных (невосстановимая приемлимыми средствами) - это часто гораздо хуже, чем отказ ПО. Следует различать разницу между отказом ПО и отказом СОД.
• Дотошность, то есть способность ПО во время функционирования предоставлять информацию, достаточную для последующего ремонта оборудования.

 Любопытен еще и такой факт. Большинство характеристик качества ПО носит объектный характер, то есть они прямо или косвенно указывают, что с этим ПО можно (нельзя) сделать. Для тех же, кто с этим ПО ничего делать и не собирается, кто хочет спокойно сосуществовать с этим ПО, обслуживая сод, для тех едва ли не менее интересны субъектные свойства ПО. Им важно, что это ПО само сможет (не сможет) сделать. Сравните "прозрачное" - сквозь которое может смотреть (кто-то другой), и "неприхотливое" - которое может (само) терпеть.