Программное обеспечение и его разработка - Фокс Джозеф М.

6. Защищает систему.

а. Она защищает свои собственные программы от «порчи» новыми, неотлаженными программами, впервые введенными в систему. (Ранее такой защиты не создавали.)

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

Операционные системы прошли длительный путь развития. В 1966 г. в журнале «IBM System Journal» была опубликована статья Мили под названием «Функциональная структура Операционной системы ОС/360»[6]. Мили отметил, что «идея операционных систем восходит по крайней мере к 1953 г., когда состоялась летняя школа по вычислительным машинам и пользовательским системам». Перед операционными системами «тогда, как и сейчас… ставили цель добиться безостановочного выполнения сразу нескольких задач и организовать библиотеку стандартных программ».

(Свое название операционные системы получили за то, что первоначально они помогали операторам поддерживать безостановочную работу машин, выполняя функции «восстановления», проводившиеся раньше самими операторами.)

Автор статьи утверждает, что основной задачей разработки ОС/360 было получение системы «одинаково пригодной как для пакетной обработки, так и для применений в реальном времени». (Эта вторая цель так и не была достигнута.) Были и вторичные цели:

— Повысить скорость решения задач

— Уменьшить время ответа

— Повысить производительность программиста

— Адаптируемость к новым условиям

— Расширяемость

Достижение всех этих целей, за исключением первой, помогает программистам. Что же касается производительности, то «ОС должна обеспечить качественно новый уровень гибкости путем предоставления программистам относительно большого набора входных языков». Ставилась также и цель по достижению независимости от внешних устройств; новая аппаратура подключается автоматически без дополнительных усилий со стороны прикладных программистов! Среди многих других функций, выполняемых ОС/360 для программистов, — связывание частей больших программ, сортировки, работы по вводу/выводу. Для управления хранением и доступом к данным в операционную систему введено восемь различных вариантов программ. Теперь программисту не нужно писать самому подобные программы, в его распоряжении имеется много способов, чтобы указывать, как это должна делать операционная система.

Системы управления базами данных (СУБД). Относительно систем управления базами данных существует большая путаница. Эти системы настолько мощны и выполняют столь широкий диапазон функций, что многие путают их подлинное назначение со «случайными» проявлениями.

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

Второй причиной создания СУБД является стремление к экономии пространства для файлов. Третья причина — это необходимость повысить достоверность информации в файлах, т. е. облегчить проверку отсутствия синхронизационных сбоев. Достоверность повышается благодаря уменьшению общего числа файлов. И наконец, с появлением СУБД облегчается доступ к данным. Многие ошибочно считают эту четвертую причину возникновения СУБД самой главной.

Как работает СУБД. Для понимания принципов работы системы управления базой данных полезно обратиться за иллюстрацией к организации авторемонтного дела. Начиная дело, я привлекаю всего трех механиков, причем каждый работает со своими собственными инструментами. Никаких стандартов пока не существует. Когда число механиков доходит до восьми, мы начинаем сталкиваться с проблемой несовместимости. Прибор, которым механик А1 устанавливает момент зажигания в автомобиле мистера Z, отличается от всех других аналогичных приборов — и, когда этот клиент начинает жаловаться, я проверяю все приборы и обнаруживаю, что все они работают по-разному! Различия между ними вызывают тревогу. Какой же из них «правильный»?

Шаг 1

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

Шаг 2

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

Шаг 3

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

С чем-то подобным мы сталкиваемся и в области программного обеспечения.

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

При таком порядке возникли три проблемы. Во-первых, программисту было очень трудно получить данные из чужого файла. Во-вторых, при изменении данных, скажем при переходе от чисел с 12 знаками к числам с 14 знаками, приходилось изменять все программы. Это было трудно, дорого, а во многих случаях просто невозможно. В-третьих, данные программиста А несколько отличались от данных программиста В. Чьи же данные были правильными?

Шаг 1

Мы утвердили стандарты на файлы — размеры, форматы, последовательности — и тем самым облегчили использование данных, подготавливаемых другими программистами.

Шаг 2

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

Это сразу избавило нас от многих неприятностей.

1. Данные хранились в меньшем числе файлов; это экономило место.

2. Стало легче отслеживать текущее состояние элементов данных.

3. Стало возможно изменять размеры данных в файлах (числа с 12 знаками на числа с 14 знаками) без изменения всех индивидуальных прикладных программ.

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

Шаг 3

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

СУБД обычно сопровождается другими программами, которые 1) обеспечивают работу с дисплеями и 2) позволяют формулировать запросы к содержимым файл на простом языке. Такой язык часто называется языком запросов. На шаге 3 создается информационно-поисковая система. Функции, определенные нами на шаге 2, уточняются таким образом, чтобы они могли помочь при поиске данных. Но это лишь некоторая дополнительная выгода, побочный эффект усилий, прилагаемых для облегчения внесения изменений в файлы. Это отнюдь не главная причина, приведшая к появлению СУБД.