Программное обеспечение и его разработка - [25]

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 1

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

Шаг 2

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

Шаг 3

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

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

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

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