Автор: admin

МИНЕСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ

(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)

Кафедра “Управление и информатика в технических системах”

Реферат на тему
“МОДЕЛИРОВАНИЕ — МЕТОД ИССЛЕДОВАНИЯ ТВОРЧЕСТВА.”

|Выполнил студент: |Старший преподаватель: |
|Найдёнов Андрей Александрович |Карпов Валерий Эдуардович |
|Подпись |Подпись |
| | |

МОСКВА 1999

МОДЕЛИРОВАНИЕ — МЕТОД ИССЛЕДОВАНИЯ ТВОРЧЕСТВА

§ 1.1. Моделирование на вычислительной машине

Моделирование, или имитация объекта исследования. Выявление существенных параметров. Роль неосознаваемый факторов при моделировании Математическое- моделирование.

. Выше .уже отмечалось, что основным методом исследования, используемым в настоящей работе, является моделирование с помощью ЭВМ. Моделирование широко используется в науке и технике как метод исследования сложных систем, поддающихся формализации, т. е. таких, свойства и поведение которых могут быть формально описаны с достаточной строгостью. В нашем случае,’когда речь идет о процессах творчества, эвристической деятельности, анализе психических функций, .игровых задачах, конфликтных ситуациях, процессах принятия решений и т. и., объекты исследований обычно настолько сложны и разнообразны, что трудно говорить об их строгой формализации, тем.- более что многие глубинные свойства перечисленных объектов (процессов) изучены еще недостаточно.
С другой стороны, в процессе многочисленных неформальных исследований этих объектов сформулированы различные, часто противоречивые умозаключения о свойствах ‘этих объектов, их
— структуре, сущности тех иди иных параметров, взаимосвязях отдельных составляющих их элементов и т. п. Совокупность этих умозаключении образует некое представление об объекте,, исследования, его неформальную., «теорию» или даже несколько взаи- моисключающих друг друга «теорий». Естественно, что такие • теории, являющиеся не чем иным, как более или менее правдоподобными гипотезами,
-нуждаются в проверке, подтверждении и установлении области их применения.

Поясним сказанное простым примером. Так, исследование музыкальных. звуков часто заканчивается на этапе анализа слуховых восприятии или/графической записи звучания, получаемой, например; -посредством прибора типа «видимый звук». Однако, формулируемые при этом выводы—лишь предположения, не всегда достоверные.
Обратимся, к анализу одного из выразительных исполнительских приемов игры на виолончели или скрипке — портаменто легато, или портаменто на один смычок- (портаменто — способ певучего .исполнения пары звуков путем лег- кого скольжения от одного звука к другому). Выводы о структурных характеристиках портаменто неправомерно делать ‘на основе анализа тех слуховых восприятии, которые получены при прослушивании исполнения музыкального произведения, где используется этот» прием, или из анализа графической записи исполнения. Ведь; одновременно неявно используются и другие, исполнительские приемы — вибрато, изменения силы звука при ведении смычка. Они накладываются друг на друга и этим затушевывают и искажают истинную картину исследуемого приема.

Из приведенного примера видно, что даже в относительно простых задачах непосредственное исследование объекта (процесса) часто оказывается весьма затруднительным и не позволяет получать надежные объективные результаты.
,

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

Так, если при исследовании мелодий какой-нибудь народности удается по закономерностям, выявленным при анализе этих мелодий, построить
(синтезировать) новые мелодии и эти мело—, дни будут восприниматься как мелодии данной народности, то тем самым потверждается предположение о том, что выявленные закономерности действительно определяют особенности мелодий рассмотренного вида. Заметим, что такое подтверждение будет убедительным, если синтез осуществлялся формально, с использованием только «сфор- мулированныз? предположений, и если при оценке результатов элиминированы субъективные факторы. Если в рассмотренном случае синтез осуществлялся не формально,, а выполнялся, например, человеком — музыкантом, которому были сформулированы те закономерности, которые следовало использовать при сочинении мелодии, такой метод проверки теряет свою доказательность и становится субъективным. Это объясняется тем, что в процессе эвристической деятельности, какой является сочинение мелодий, человек может даже неосознанно реализовывать какие-то дополнительные закономерности, помимо заданных. Эти дополнительные неосознанные закономерности и факторы часто могут играть весьма существенную роль, а заданные, осознанные закономерности могут оказаться и несущественными, что подтверждается многочисленными примерами из разных областей творческой деятельности- человека, таких, например, как живопись, музыка, различные игры.

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

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

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

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

В основе математического моделирования на ЭВМ лежит математическая модель,т. е. формальное описание известных или предполагаемых закономерностей, выявленных При содержательном, эвристическом анализе исследуемого объекта. Модель эта реализуется в виде машинного алгоритма, результат работы которого—описание имитируемого процесса или исследуемого явления. При моделировании процесса сочинения музыки, напримёр, конечный результат — нотная запись музыкального текста и перечень’тех закономерностей, которые участвовали в его синтезировании

Естественно, что ничего «своего», не осознанного предварительно человеком, модель и алгоритм не содержат. Критерием качества такого математического моделирования, критерием правильности и полноты составленной модели является степень сходства полученных на ЭВМ результатов с результатами соответствующей человеческой деятельности. Неудовлетворитель- ность машинных результатов объективно доказывает неполноту или неправильность исходных посылок, использованных при составлений и алгоритмической (программной) реализации математической модели, и требует пересмотра исходных посылок, дополнения модели новыми данными, т. е. совершенствования построенной модели.

При моделировании на вычислительной машине, таким образом, объективно проверяется достаточность тех знаний, которыми;.обладает машина (или, точнее, ее: программа’); для реализации изучаемого процесса или объекта.
Такое моделирование позволяет подтвердить наши Предположения, гипотезы, о механизме исследуемого объекта или процесса, о его закономерностях, правомерность наших представлений о структуре объекта, а также помогает установить степень его изученности.
Составление алгоритма (машинной программы) требует формализации всех элементов и структуры исследуемого объекта, . входящих в этот алгоритм, и тем самым способствует логической ясности в понимании его. Непременным условием при: этом является строгая и формальная точность определения,
(раскрытия содержания) всех понятий, вводимых в программу.

§ 1.2. Три этапа моделирования

Дифференциальный и целостный подходы при моделировании. Анализ, синтез, оценка модели—три этапа моделирования. Способ» .оценки модели. Трудности объективной (межличностной) оценки моделе объектов• художественного творчества: необходимость специального эксперимента для преодоления психологической установки экспертов. Цель машинного творчества—не создание шедевров»

Для моделирования существенно объединение дифференциального
(атомистического) и структурно-целостного подходов, диалектическое единство анализа и синтеза при исследовании изучаемых явлений. Моделирование заключается в имитации изучаемого явления. Точность имитации определяется путем сравнения полученного при воспроизведении результата с его прототипом, объектом исследования, и оценки степени их сходства.

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

Рассмотрим более» детально эти этапы.

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

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

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

На том же этапе исходные предположения переводятся на четкий однозначный язык количественных отношений и устраняется нечеткие, неоднозначные высказывания или определения, которые заменяются, быть может, и приближенными, но четкими,; не- допускающими различных толкований высказываниями

Формирование (синтез) модели представляет собой второй этап моделирования. На этом этапе в соответствии с задачами исследования осуществляется воспроизведение, или имитация, объекта на ЭВМ с помощью программы, которая включает в себя закономерности и другие исходные данные, полученные на этапе анализа. Структура модели, существенно зависит от задач исследования.. Так, например, если проверяется полнота и правильность наших знаний об объекте, последний имитируется с использованием, всех известных исходных соотношений. Если же задача, заключается ,в проверке некоторых предположений и степени; их общности, то именно эти предположения вводятся в программу и в результате имитации получаются объекты, которые
‘лишь частично отражают -реальные свойства имитируемого объёкта:

Оценка машинных результатов, заключается, в установлении адекватности модели и объекта исследования — в определении степени’ близости,, сходства, машинных и человеческих действий или их результатов.
При этом существенно не «абсолютное качествo» машинных результатов, а степень сходства с объектом исследования. Так, .при моделировании
‘музыкальных сочинений важно нe то, чтобы машинная музыка была «лучше» музыки композиторов-классиков, а чтобы она была похожа на ту, которая исследуется, и—в идеале — была от нее неотличима (по эмоциональности, по выразительности, по синтаксической сложности, принадлежности к типу, стилю и т. п.).

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

Нет

Да

Вход

Выход

Рис. 2.1. Схема многоэтапного модели рования.

Чаще, однако, первые результаты моделирования не удовлетворяют предъявленным требованиям. Это означает, что по крайней мере в одной из перечисленных выше позиций (изученность объекта, исходные принципы, алгоритм) имеются дефекты. Это требует проведения дополнительных исследовании и соответствующего изменения машинной программы, после чего снова повторяются второй и третий этапы. Процедура повторяется до получения надежных результатов. Такая схема многоэтапного моделирования, используемого в самых разнообразных исследованиях, приведена на рис. 2.1.
‘

Этап оценки модели является важным этапом моделирования. В зависимости от характера объекта исследования и поставленных задач ‘применяются различные методы оценки модели. Особенно большое значение имеет правильная опенка модели, когда моделирование, используется для проверки гипотез, а также когда объекты недостаточно формализованы и нет строгого объективного критерия сходства объекта и модели. С подобной ситуацией часто приходится встречаться при моделировании интеллектуальных, творческих процессов.
Рассмотрим поэтому вопросы Оценки моделей несколько более подробно.
Модель должна обладать существенными признаками объекта моделирования.
Иначе.говоря, модель и объект должны быть неотличимы по этим признакам, которые выбираются, вообще говоря, исследователем в зависимости от цели и. задачи исследования.’ Так, чучело птицы моделирует внешний вид птицы, но не моделирует ее динамического состояния, например полета. Самолет-орнитоптер
(летательный -аппарат с машущими, крыльями)’ не моделирует внешнего вида птицы, зато моделирует ее полет. При моделировании творчества также имитируются лишь отдельные стороны объекта, наиболее интересные (или доступные) для исследователя.
Наличие существенных для объекта признаков в модели определяется по- разному, в зависимости от его вида. В одних случаях эти признаки обнаруживаются непосредственно: например, в модели гармонизации—путем отыскания ошибок, в модели шахматиста (шахматной программе)—по результатам игры с настоящими шахматистами. В других случаях существенные признаки оказываются «скрытыми» и для их отыскания приходится прибегать к специальному эксперименту. Как правило, это имеет место при оценке моделей художественных произведений.

Как известно, художественные произведения относятся к тому упомянутому выше виду объектов, для оценки которых не существует объективных критериев. Так, одно и то же музыкальное произведение разными критиками оценивается по-разному. И более того, как показывает «практика, один и тот же (даже профессиональный) критик одно и то же произведение в разное t время может оценивать тоже по-разному. На оценку влияют ‘разные факторы: привычка, субъективный опыт, вкус, общественное мнение, -дух. противоречия этому мнению и многие, многие другие. Весьма важна и психологическая установка (предвзятость) по отношению к произведению, его автору, жанру, стилю и тому подобным параметрам оцениваемого произведения.

Все вышеуказанное относится к художественным произведениям, созданным профессиональными авторами, например композиторами-профессионалами.
Проблема значительно осложняется, когда требуется оценить машинное сочинение —стихи или музыку. Здесь особенно ощутимо проявляется психологическая предвзятость эксперта по отношению к. машинному творчеству.Эта предвзятость проявляется двояким образом: либо отрицание
«творческих» возможностей машины, когда эксперт, даже не ознакомившись с машинным сочинением, не прослушав его, заранее «знает», что «машина не может»,’либо восторженное почитание машинного творчества. Эксперты и первого, и второго типа не могут объективно (без предвзятости) оценить машинное сочинение, и нужен специальный эксперимент, в ходе которого их установка могла бы быть разрушена.

Задача такого объективного в социологическом смысле эксперимента — преодоление психологической установки экспертов по •отношению к машинному творчеству (модели), создание таких условий, чтобы они заранее не знали, оценивают ли они человеческие произведения или их машинные модели.

Методика подобного социологического эксперимента для оценки машинной и человеческой музыки была разработана автором (Р. X. Зарипов, 1971а)*). При этом задача заключалась в получении сравнительной оценки человеком мелодий, сочинен-

*) Нам неизвестно, проводились ли подобные социологические эксперименты-
«плебисщиты» зарубежными исследователями. Во всяком случае, в за-рубежных публикациях, посвященных применению ЭВМ в музыке, описы-вается лищь эксперимент, разработанный автором настоящей книги (см., ‘например,
Зелинъски, 1973; Пиотровски, 1975; Копржива, 1972 и др.). ных профессиональными композиторами и машиной. Проблема оценки машинных композиций и сравнения их с сочинениями композиторов может решаться только путем опроса самих слушателей. Эта проблема ‘ связана с особенностями психологии слушателей, воспринимающих музыку, которые не могут объективно оценить композиции, если они .наперед знают, что, скажем, мелодия 1 — машинная, а 2 — человеческая, подобно тому, как нельзя объективно оценить популярные, «запетые» мелодии. Поэтому для объективного сравнения слушатели не должны знать, что они в данный момент оценивают—машинную или человеческую музыку.

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

Для эксперимента были выбраны мелодии песен известных советских композиторов, опубликованные в сборниках избранных песен, и мелодии, сочиненные на вычислительной машине «Урал-2». Все мелодии проигрывались в произвольном порядке, неизвестном слушателям-экспертам, которые оценивали их по пятибалльной системе и оценки записывали на бланках-протоколах.
Эксперимент проводился в разных социомузыкальных группах, в каждой из них уровень музыкальной подготовленности участников эксперимента мог считаться примерно одинаковым. Это были студенты Московского энергетического института, студенты Государственного музыкально-педагогического института имени Гнесиных, участники Всесоюзного симпозиума «Проблемы художественного восприятия», школьники старших классов, математики — участники методологического семинара Математического института АН СССР имени В. А.
Стеклова и Вычислительного центра АН СССР, работники предприятий культуры . и др. Всего в эксперименте участвовало более шестисот человек*). Кроме того, подобный «плебисцит» был проведен на основе передач по первой программе Центрального радиовещания 25 августа 1973 г., 29 июня 1976 г. и
15 июля 1980 г.

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

|Оценка,бал|5 4 |,1 |С. |
|лы |3 2 | | |
|Машина |76 253 |5 |3,6|
| |204 22 | |7 |
|Композитор|61 213 |8 |3,5|
|ы |247 31 | |.1 |

Здесь показано, сколько различных оценок (5, 4, 3, 2, 1)-полудили мелодии, сочиненные машиной и композиторами; С— соответствующие средние оценки за мелодии.

Хотя эксперты не знали, какую — человеческую или машинную — музыку они оценивают, некоторые из них высказывались довольно категорично: «Вся машинная музыка — не музыка, нет чувства», «Да чтобы я не отличил машинную музыку от человеческой!», «Много чрезмерно периодичных, туповато-машинных тем». Но—ирония судьбы—именно эти эксперты, не осознавая и не желая того, оценили выше машинную музыку. Их «очевидное» представление о машинной музыке оказалось ошибочным.

Весьма показателен в этом смысле и «плебисцит», проведенный на основе передачи по первой программе Центрального радиовещания 29 июня 1976 г. Цель его—выяснить; как радиослушатели оценивают творческие возможности машин и какой они представляют себе машинную музыку. Для этого им предложили прослушать три мелодии и определить, кто является их автором—человек или машина. Результат, опроса в отношении одной из мелодий был неожиданным. В своих письмах радиослушатели отмечали, что в этой мелодии «чувствуется душа», она «отличается мелодичностью, пленяет слух, проникает в сердце», что «конечно же, такую музыку мог написать только человек», «никакая машина не сможет заменить человека в этом тонком творческом процессе, и не надо пытаться это делать».

Авторы 125 писем (из 130, поступивших в редакцию) были твердо убеждены, что эта мелодия написана композитором (только 5 человек с некоторыми оговорками приписывали ее машине). И 125 человек из 130, хотели они этого или нет, дали тем самым весьма высокую оценку творческим возможностям машины, показав ошибочность своего представления о машинной музыке. А мелодию эту сочинила машина по программе автора, описанной ниже
(см. гл. 5).

Часто оказывается, что если слушатели не знают о «нечеловеческом» происхождении музыки, то и воспринимают ее как вполне «нормальную», не отличающуюся от обычной. Так, на Международном совещании по искусственному интеллекту, проходившем в городе Репино (под Ленинградом) в 1977 г., на русском и английском языках прозвучала «ИИ-кантата»—своего

-ИИ-КАНТАТА»
[pic]
Рис. 2.2. Гимн искусственному интеллекту.

рода гимн искусственному интеллекту, сочиненный по предложению Оргкомитета совещания (рис. 2.2). Слова написал А. Аверкин, а музыка была сочинена на машине «Урал-2» по программе, описанной в книге Р. X. Зарипова (1971а).
Исполненная в непринужденной обстановке оркестром и певцами, эта песня была воспринята как обычное музыкальное произведение, и не все участники совещания сразу поверили, что — музыку этого гимна сочинила машина*).
Результаты этого эксперимента, проведенного многократно, подтверждают следующий факт: при моделировании на ЭВМ таких форм музыкального творчества, как сочинение мелодий массовых песен, получены машинные результаты, которые не -только соизмеримы с человеческими, но в ряде случаев превосходят последние по качеству. Это позволяет судить о высокой степени изученности механизма порождения таких мелодий и подтверждает правильность выбранных принципов моделирования.
Этот эксперимент представляет собой реализацию идеи Тьюринга об испытании на интеллектуальность («игре в имитацию»)
__________________________________________________________________

*) Заметим, кстати, что все нотные примеры, полученные машиной по программам автора, публикуются им без всяких изменений и корректировок.

ИИ-КАНТАТА
Музыка ЭВМ «Урал-2» Слова А. Аверкина
Вас встречает Решино—
Тут простор мечтам.
Интеллект искусственный
Мудр не по летам.
Диалог с программами,
ЭВМ с экранами,
Шимпанзе с бананами
Мы покажем вам.

Припев:
Искусственный интеллект
Стал теперь проблемой века.
С искусственным интеллектом
Мы прославим человека. ;
Нам читают лекции
Главные спецы —
Всех систем искусственных
Деды и отцы.
Фреймы и сценарии
Внукам мы оставили,
Пусть в них разбираются
Наши молодцы.

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

Припев

AI-CANTATA
Music: Computer «Ural-2» Text: A. Averkin
We meet. you in Repino — Hope, we’ll be kind. •Artificial Intelligence Has a plastic mind, Look at machine’s conversation, Robot’s travel simulation,
Monkey in logic of action And what else you’ll find.

Refrain:
Artificial Intelligence!
It became the greatest problem.
Artificial Intelligence!
It glorifies Homo Sapiens.
At the joint conference There are experts — Of every system intellect
Dadies and granddads. Frames and scripts in memory We present to our children, Now they are studied by Our progeny.

Refrain
We’re discussing Robotics. Outside it’s spring, ‘ Add spring to your Theory
— It will be complete. • Let it. be the robot’s peace With a swinging proboscis. We’ll empty a frendly glass And then we shall sing.

Refrain применительно к музыке. Тьюринг (А. Тьюринг, 1960) предложил судить о наличии «интеллекта» по результатам «игры в имитацию», которая сводится к следующему. В игре участвуют некое лицо (эксперт) и две системы А и В, одна из которых—человек, а другая — машина; Эксперт, не видя этих систем, задает любые вопросы системам А и В и, анализируя их ответы, должен определить, какая из них является машиной. Если он не сможет, определить этого в течение заданного временив то такая машина считается «интеллектуальной».
Из результата упомянутого выше эксперимента следует; что программа- композитор, синтезирующая эти мелодии, выдерживает тест Тьюринга*).
__________________________________________________________________

*) Напомним, что создание программ, выдерживающих тест Тьюриига, входит в перечень конкретных задач, относимых к проблеме искусственного интеллекта
(см. введение).

Нужно отметить, что мелодии композиторов в эксперименте — независимо от та качества или: отношения к ним слушателей — являются результатом той профессиональной деятельности-человека, которую принято называть творчеством. Здесь имеется в виду, что продукты художественного творчества
—это не только мировые шедевры искусства: Седьмая («Ленинградская») симфония Д. Шостаковича в интерпретации Е. Мравинского, «Вариации на тему рококо» П. Чайковского в исполнении Д. Шафрана, романс «Я помню чудное мгновенье» М. Глинки в исполнении И. Козловского и. т. п., но и многие тысячи других произведений. Поэтому не следует нигилистически отмахиваться от тех продуктов художественного творчества, которые по тем или иным причинам не стали шедеврами или просто популярными, ибо причина популярности художественного произведения — особая проблема, не изученная до настоящего времени.

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

У композитора—члена Союза композиторов СССР—высокий уровень профессионализма и мастерства; у композитора, окончившего консерваторию (и не только Московскую),— тоже достаточно высокий уровень, чтобы произведения его» могли быть эталоном в подобном эксперименте. Ведь мелодия такого композитора обязательно включает в себя элементы профессионализма. Студенты на учебных занятиях «набивают руку» в технике и впоследствии используют эти навыки в своей творческой практике уже автомагически. Все это особенно ощутимо проявляется в тонкостях, в деталях, что, собственно, и отличает профессионала от дилетанта, от самодеятельного сочинителя музыки.
Композитор-профессионал просто уже органически не может писать как дилетант, ибо он приучен или привык писать профессионально. (Чтобы предостеречь очевидные возражения, следует сразу же оговориться: здесь имеются в виду общие правила, а не возможные исключения из них.) Таким образом, эксперимент помогает оценить степень «профессионализма» в машинной музыке, а отнюдь не степень ее «художественности».

Остановимся теперь на высказываниях некоторых участников эксперимента о том, что мелодии композиторов, использованные в эксперименте, серые и бездарные, и только поэтому машинные мелодии получили более высокую оценку.
Авторы этих высказываний, находясь под гнетом установки «машина не может», забывают, что задача заключается пока не в машинном создании шедевров или произведений искусства, а прежде всего в выявлении закономерностей музыкальных композиций как результата творческого процесса д в их машинном воспроизведении. Кроме того, проблема заключается и в способе отыскания объективных (межличностных) критериев оценки продуктов художественного творчества.

Оппонентам трудно изменить установку, отношение к понятию художественного творчества. Следует, однако, помнить что знакомые многим, а тем более любимые произведения, это лишь малая часть—капля .в океане того, что создается в результате художественного творчества. А все остальные произведения — как это ни печально и ни горько для их авторов — остаются безвестными и часто никогда и ‘никем не исполняются, но от этого они не перестают быть продуктами художественного творчества. Здесь часто происходит терминологическая путаница. Понятие о продукте (или результате) художественного творчества необоснованно смешивается с понятием о произведении искусства, к которому предъявляются повышенные эстетические требования, а эту тонкость в понятиях, очевидно, не все улавливают.

Аналогичная ситуация имеет место ив других видах художественного творчества.

§ 1.3. Синтезирование — частный случаи моделирования

Синтезирование и моделирование. Синтезирование в музыке.

Выше уже отмечалось, что один из этапов моделирования — синтез, построение модели и воспроизведение результата функционирования этой модели
(синтез результата). В общем случае такое синтезирование не является самоцелью, а служит для последующего„сравнения модели с оригиналом, в результате которого проверяется соответствующая теория и гипотеза;
Бывают, однако, случаи, когда цель экспериментов—синтезирование нового, и тогда сходства с оригиналом не требуется; больше того, оно может оказаться нежелательным. Так, средства электронного синтеза— электромузыкальные инструменты—позволяют получать тембры, как имитирующие классические музыкальные инструменты (скрипка, кларнет, рояль и т. п.), так и новые, неизвестные в музыкальной практике. В первом случае происходит моделирование известных тембров, во втором более уместно говорить .просто о синтезировании новых тембров. Очевидно, что первое значительно труднее—ведь для этого надо знать количественные характеристики звучания инструментов.

Другой пример. Моделирование и синтезирование (сочинение) музыки имеют между собой много общего и внешне вроде бы не отличаются друг от друга: ведь результатом как моделирования, так и сочинения (синтезирования) музыки на вычислительной машине служат музыкальные композиции—музыкальные пьесы, записанные в виде обычной нотации. Однако моделирование музыки не сводится к синтезированию (сочинению) музыки. Для моделирования необходима знать параметры имитируемого объекта тогда как просто для синтезирования этого не требуется,— любой произвольный набор параметров синтезирует обязательно что- то, но не моделирует. Таким образом, моделирование и собственно синтезирование (сочинение) имеют разные цели, разные задачи. Иначе говоря, моделирование—это синтезирование с последующей оценкой сходства модели и оригинала.

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

Уже упомянутая выше сложность постановки объективного эксперимента при моделировании музыкальных объектов привела на Западе к тому, что исследователи постепенно стали переходить от идеи моделирования (в первых экспериментах; см. о них в обзорной части книги: Р. X. Зарипов, 1971а) к значительно легче осуществимой идее синтезирования музыки, структура которой существенно отличается от ранее известной музыкальной структуры.
Это же, по существу, признает в своем обзоре об использовании ЭВМ при сочинении музыки и американский композитор Хиллер (Хиллер, 1970), называющий мелодии традиционной структуры (мелодии массовых песен) народными мелодиями (folk-tunes).

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

При сочинении такой музыки использование вычислительных машин оказалось очень удобным для получения различных вариантов звуковых сочетаний, из которых композитор выбирает подходящие по своему усмотрению. Таким образом, машина используется для производства заготовок, черновых вариантов звуковых сочетаний. Синтезирование огромного количества возможных вариантов таких сочетаний вручную весьма затруднительно и требует большого времени и кропотливого, отнюдь не творческого труда. Кроме того, те сочетания (лишь весьма малая доля из всех возможных), которые композитор получает вручную, часто плохо подходят для выражения творческого замысла. Нужны талант большого мастера и огромная творческая интуиция, чтобы среди множества потенциально возможных комбинаций увидеть (или точнее—.услышать) комбинацию подходящую, созвучную’ задуманной идее. Эта задана подобна проблеме «видения» мелодии темы для написания фуги — особой формы полифонического произведения. Как известно, не любая наперед заданная мелодия годится в качестве темы для сочинения фуги. Об этом можно судить хотя бы по следующему высказыванию С. С.
Скребкова:«…путь, исходящий из предварительного сочинения всей темы целиком, заведомо связан со случайностью и ни в коей мере не гарантирует успеха» (С. С. Скребков, .1951, с. 223). И лишь вы- . дающиеся мастера полифонического искусства могут интуитивно чувствовать, пригодна ли данная мелодия для полифонической (и, в частности, канонической) разработки (см., например, Е.Корчинский, 1960). ‘
Мысль о применении вычислительных машин для изготовле-ния заготовок в поэтическом творчестве (например, составление заготовок рифм или полного словаря русских рифм, включая и классические точные, и современные неточные рифмы) не раз высказываласьи в нашей печати (см., например, С.Л Соболев,
1963; А.М.Кондратов, 1963).
Перебор возможных вариантов (и, следовательно, их подготовка или сочинение) занимает большое место в различных видах творчества — художественном, изобразительном или научном.
Разработка методов комбинирования звуков для получения соответствующих заготовок музыкальных фраз имеет большую историю. Этим, например, занимался ещё в XVII веке французский теоретик музыки Марен Мерсенн (Куме, 1972). В своих музыкальных трактатах Мерсенн часто иллюстрирует изложение численными примерами, в частности, из области элементарной комбинаторики. Так, например, Мерсенн изучал закономерности структуры 8!= 40320 «песен»—мелодии из восьми нот (высот звуков с одинаковыми длительностями), полученных в результате перестановок. Его интересовали правила искусства комбинировать, которые бы помогли композиторам «делать хорошие песни», поскольку он устанавливал связи .выразительных музыкальных средств и приемов композиции с определенными эмоциями.

По-видимому, в стихотворном творчестве-машина еще не использовалась для производства заготовок поэтических элементов. В музыке же эта идея оказалась весьма плодотворной. Она реализована в творчестве таких, например, композиторов нетрадицион-ного направления, как Я. Ксенакис, П.
Барбо (А. Моль, 1975), Р. Ружичка (1972, 1980), Л. Аствацатрян (1977) и др.

Использование машинных заготовок пригодно и для получения сочинений традиционной музыкальной системы. На рис. 2.3 риведена музыкальная пьеса, сочиненная итальянским математиком и музыкантом
Гальярдо и названная им «Русской песней». Мелодия неликом составлена из заготовок, в качестве которых были использованы отрывки (в основном однотактовые) мелодий, сочиненных ЭВМ «Урал-2» по программе автора этой книги (Р. X. Зарипов, 1971а). Аккомпанемент составлен формальным

Э. Гальярдо.» Русская песня»

[pic]

Рис, 2.3. Музыкальная пьеса, сочиненная Гальярдо, как пример сотрудничества человека и ЭВМ.

способом в соответствии с музыкальной теорией, разработанной Гальярдо
(Гальярдо, Форназари, 1978)*).

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

Такой способ может быть полезен для получения практических’ результатов при сочинении профессиональной музыки, и он используется, как уже было сказано выше, некоторыми композиторами — это метод заготовок вариантов различных фрагментов музыки. Полученные машиной варианты требуют отбора, который производится композитором,—наиболее удачные сочетания он включает в свое произведение. Как и для всякой человеко-ма-шинной системы, этот метод применим для повышения эффективности при получении практических результатов. Для осознания же исследуемого процесса, осознания каждого его этапа более
__________________________________________________________

*) В предисловии Гаяьярдо к книге Р. X. Заришова (,1979) эта мелодия приводится как пример сотрудничества человека (Гальярдо)^ и машины («Урал-
2»)-/в области сочинения музыки,’когда отбор машинных заготовок и изменение в них некоторых ног производятся по усмотрению композитора. пригоден такой метод моделирования, при котором конечный результат получается машиной без вмешательства человека и где контролируется каждый шаг работы машины.

§ 1.4. Трудности моделирования творческой деятельности

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

Здесь пойдет речь не о тех технических трудностях моделирования творческой деятельности, которые связаны с недостаточным вниманием к этому кругу проблем или с затруднениями по практическому использованию вычислительных машин специалистами гуманитарного профиля (музыкантами, традиционными психологами, литераторами и т. д.). И даже не о тех- препятствиях, которые ставят развитию работ по моделированию творчества и искусственному интеллекту некоторые авторы, считающие, что создание искусственного разума есть миф, отнимающий известное количество сил и средств и отвлекающий кибернетику от решения ее прямых задач. Такого рода трудности и препятствия, разумеется, сильно тормозят развитие этих работ.
Однако, не являясь принципиальными, они рано Или поздно будут преодолены.
Здесь уместно напомнить высказывание И. А. Полетаева (И. А. Полетаев,
1971): «Невозможно выключить «рубильник науки». Нельзя прекратить исследования генетического анализа и синтеза, нельзя закрыть Америку. Если человек может открыть Америку, полететь на Луну, синтезировать живое существо, построить мыслящее механическое чудовище, он непременно и неизбежно все это сделает, даже если его не побуждает к этому прямая нужда.
Просто—таков человек! Почему он таков—мы не знаем, но узнаем, ибо человек
(не этот, так следующий) и это узнать не побоится».
В этом параграфе будут рассмотрены некоторые принципиальные трудности, связанные со спецификой таких объектов моделирования, как интеллектуальные процессы и творческая деятельность. Основная трудность, видимо, заключается в недостаточной изученности (скорее—в полной неизученности) закономерностей механизма интуиции, лежащего в основе этой деятельности.
С этим же связана и недостаточная изученность проблемы понимания в .широком смысле, когда имеется в виду не только понимание в диалоге, но и понимание, осознание целей и результатов интеллектуальной деятельности. Отсюда следует и практическая трудность в моделировании творческих процессов
(эвристической деятельности и психических функций), заключающаяся в необходимости отыскания и формализации тех элементов творческого процесса, которые свободно и неосознанно реализует человек. В процессе творческой деятельности при решении различных задач человек обычно не разлагает процесс отыскания решения на элементарные операции, содержащиеся в нем, реализуя многие из них. неосознанно и автоматически. Так, он не задумывается, по каким формальным признакам он практически безошибочно отличает на фотографии мужчину от женщины, узнает своих знакомых по внешнему виду, или, разговаривая по телефону, по голосу, успешно выделяя их из множества других людей. Так же неосознанно мы безошибочно отличаем грузинскую . мелодию от русской, хотя и не сможем объяснить, каким образом.
Любопытно, что это безошибочно делают и те, кто не обладает даже минимальными познаниями в музыке *).
Для алгоритмизации же и для моделирования на электронной вычислительной машине подобных процессов необходимо внести в программу все сведения об объекте, формализовать все те операции, которые человек обычно совершает интуитивно. Машине необходимо точно и однозначно сообщить все детали и уточнения, все те сведения об объекте исследования, которые на самом деле важны, существенны для успешного решения задачи. В противном случае результат моделирования будет лишен характерных черт исследуемого объекта и будет неадекватен оригиналу.

Существенной трудностью машинного моделирования является также и то, что в силу различия особенностей функционирования машины и человека целый ряд задач, трудных для человека, легко решается машиной, а многие задачи, с которыми человек расправляется шутя, с большим трудом решаются на машине.
Так, человек легко читает даже незнакомый почерк—машина, несмотря на многолетнюю упорную работу в этом направлении многих научных коллективов как в нашей стране, так и за рубежом „ (В. С. Переверзев-Орлов, 1976), пока этого делать не умеет.
Зато, например, при разложении иррационального числа 2 в бесконечную цепную дробь {А. Н. Хованский, 1956)

современная электронная вычислительная машина за считанные минуты позволяет получить несколько тысяч неполных частных а1 (а,—целые положительные числа, i=i, 2, ,..), тогда как необходимость оперировать с большими числами служит препят-
____________________________________________________________________

*) Заметим, что роль и значение отдельных привнагов, а также последовательность их проверки при «человеческом» опознании непостоянны, а раз от разу меняются. Так, для узнавания человека иногда существенны походка, внешний облик, прическа, в Других .случаях—голос, черты лица и т. ед. Это, в частности, проверяется простым экспериментом, когда опознающему предъявляются отдельные части фотографии опознаваемого, иа которых отсутствуют те или иные детали, (Прим. ред.) ствием при вычислении вручную даже нескольких десятков величин а,. При получении одной тысячи элементов a, Ct=l, 2, … …,1000) приходится в промежуточных выкладках иметь дело с числами порядка 10″, где а примерно равно двум-трем тысячам. Такое число очень велико, и если выписать подряд все его цифры, то оно вряд ли уместится на одной странице печатного текста.
И эти числа надо многократно складывать и делить одно на другое.
С аналогичной трудностью встречаются и в музыкальном творчестве. Человек, никогда не обучавшийся музыкальной грамоте, легко может придумать мелодию на заданные стихи — сочинить песню. (Это очень ловко делают даже дети в детском саду.) Составить же программу, по которой бы машина сочиняла мелодии такой же сложности (такой синтаксической структуры),—дело очень трудное. Здесь у человека проявляется интуиция. подражания— ведь он сочиняет песню на основе своего прошлого опыта, приобретенного им в качестве слушателя. По-видимому, человек, Никогда не слышавший песен, не сможет и сочинить никакой мелодии.
С другой стороны, как показывает практика, гармонизовать мелодию (что делают на занятиях по курсу гармонии в музыкальных училищах или в консерватории) значительно труднее, чем сочинить мелодию. Гармонизация мелодии в общих чертах (на первом этапе обучения) заключается в следующем.
Задается мелодия в виде последовательности нот. К каждой ноте мелодии надо подобрать соответствующий аккорд, представляющий собой упорядоченный набор четырех звуков (или голосов, имеющих следующие названия: сопрано, альт, тенор, бас). При этом соедине-‘ ние аккордов осуществляется по определенным принципам и правилам, выработанным художественной практикой. Гармонизация мелодии требует знания многих специфических правил и рационального, осознанного применения их при решении таких задач. Интуиция ‘здесь, как правило, не помогает. Составить же программу для вычислительной машины, которая бы хорошо решала задачи по гармонизации, намного легче, чем составить программу для сочинения хороших мелодий*).
Разные задачи человек решает по-разному, и ему не все равно, как он это делает —осознанно или неосознанно — путем вычислений, расчетов, сравнений или интуитивно, без всяких вычислений. Человеку легче решать задачи без вычислений — например, задачи на подражание, узнавание или распознавание
____________________________________________________________________
*) Так, решения задач по гармонизации мелодии, выполенные машиной «Урал-2»
(Р. X. Зарипов, 1968, 1971а) в соответствии с требованиями, которые предъявляются студентам при выполнении такой работы, были оценены (в 1965 г.) преподавателем Музыкального училища, В. Н. Холоповой на «отлично», а профессором Московской консерватории С. С. Скребковым— на «хорошо». На оценку этих безошибочных решений в консерватории повлияла повышенная требовательность к «художественности» гармонизации — одной лишь безошибочности здесь оказалось недостаточно. образов. Для того же, чтобы такие, задачи решались на машине, ей нужен алгоритм — система однозначных и точных предписаний, далеко не всегда известная человеку.
Говоря о трудностях такого рода при моделировании жизненных процессов, И.
А. Полетаев в одном из своих’ выступлений (на конференции «Математическое моделирование жизненных процессов», Москва, 17—18 марта .1966 г.) сказал:
«Если хотите убедиться, что вы плохой специалист (психолог, биолог, социолог и т. п.), попытайтесь сделать хорошую модель Увидите, как вы» плохо знаете предмет».
Сложная ‘ деятельность (психическая, эвристическая, продуктивная) внешне часто представляется простой лишь потому, что в ней незаметно, не обнаруживая «себя, вступает в действие механизм интуиции—подражания- или. узнавания, до сих пор изученный очень слабо. Простой же эта деятельность кажется из-за того, что ‘в ней используется мало правил, либо их вообще нет
(как при узнавании друзей по их голосам). Но правила всегда нужно применять осознанно —по ним надо вычислять, а это — неестественное и некомфортное занятие для человека. Поэтому они всегда заметны, и чем меньше правил используется в продуктивной (эвристической) деятельности человека, тем она кажется ему проще и легче.
И лишь при построении модели такой деятельности, при ее ‘ формализации и машинном моделировании выясняется, как мало мы о ней знаем и как много делается по интуиции при ее ручной, или субъективной реализации.
Воспроизводя (моделируя) объект исследования и совершенствуя его модель, мы шаг за шагом проникаем в суть объекта., познаем его существенные, характерные свойства, попутно убеждаясь в несущественности других его свойств или признаков (которые прежде казались существенными). Говоря образно, мы можем до конца понять лишь тот мир, который строим сами.
Специфика самого метода моделирования на ЭВМ и рассмотренные выше трудности моделирования требуют на первых порах . ограничиваться наиболее простыми синтаксическими структурами объекта исследования для выявления принципиальных, наиболее существенных сторон как самого метода моделирования, так и изучаемого объекта. В этом тоже заключена определенная трудность, так как при исследовании какого-либо объекта с помощью электронной вычислительной машины, как показывает практика, всегда есть большой соблазн сразу же получить сложный машинный результат. В данном же случае поддаться соблазну—не лучший способ его преодолеть.
Так, при моделировании музыкальных сочинений некоторые программисты, не имея предварительной подготовки в исследовании музыки, начинали моделирование с вальсов Штрауса. Это очень сложная структура, особенно для начинающих, поэтому неудивительно, что все их попытки (без исключения) постигла неудача: ни в одном случае не было даже закончено составление программы. Наступившее разочарование навсегда отбило у авторов этих программ охоту заниматься подобным делом.
Как показывает опыт моделирования сложных систем, целесообразнее начинать исследовать не весь объект в целом, не всю сложную систему, а его фрагменты, отдельные его стороны или явления, т. е. строить эскизные модели объекта. Все это на первых этапах неизбежно приводит к схематизации, определенному упрощенчеству (часто намеренному, сознательному) в постановке и решении задач, но позволяет получить полезные результаты и использовать их при решении более сложных задач.

————————

Анализ

Синтез

Оценка

МОДЕЛИРОВАНИЕ — МЕТОД ИССЛЕДОВАНИЯ ТВОРЧЕСТВА
§ 1.1. Моделирование на вычислительной машине
Моделирование, или имитация объекта исследования. Выявление существенных
параметров. Роль неосознаваемый факторов при моделировании. Математическое
моделирование.
. Выше .уже отмечалось, что основным методом исследования, используемым в
настоящей работе, является моделирование с помощью ЭВМ. Моделирование широко
используется в науке и технике как метод исследования сложных систем,
поддающихся формализации, т. е. таких, свойства и поведение которых могут быть
формально описаны с достаточной строгостью. В нашем случае, когда речь идет о
процессах творчества, эвристической деятельности, анализе психических функций,
.игровых задачах, конфликтных ситуациях, процессах принятия решений и т. и.,
объекты исследований обычно настолько сложны и разнообразны, что трудно говорить
об их строгой формализации, тем более что многие глубинные свойства
перечисленных объектов (процессов) изучены еще недостаточно.
С другой стороны, в процессе многочисленных неформальных исследований этих
объектов сформулированы различные, часто противоречивые умозаключения о
свойствах этих объектов, их — структуре, сущности тех иди иных параметров,
взаимосвязях отдельных составляющих их элементов и т. п. Совокупность этих
умозаключении образует некое представление об объекте,, исследования, его
неформальную., “теорию” или даже несколько взаимоисключающих друг друга
“теорий”. Естественно, что такие теории, являющиеся не чем иным, как более или
менее правдоподобными гипотезами, нуждаются в проверке, подтверждении и
установлении области их применения.
Поясним сказанное простым примером. Так, исследование музыкальных. звуков часто
заканчивается на этапе анализа слуховых восприятии или/графической записи
звучания, получаемой, например; -посредством прибора типа “видимый звук”.
Однако,
формулируемые при этом выводы — лишь предположения, не всегда достоверные.
Обратимся, к анализу одного из выразительных исполнительских приемов игры на
виолончели или скрипке — портаменто легато, или портаменто на один смычок-
(портаменто — способ певучего .исполнения пары звуков путем лег-
кого скольжения от одного звука к другому). Выводы о структурных характеристиках
портаменто неправомерно делать на основе анализа тех слуховых восприятии,
которые получены при прослушивании исполнения музыкального произведения, где
используется этот» прием, или из анализа графической записи исполнения. Ведь;
одновременно неявно используются и другие, исполнительские приемы — вибрато,
изменения силы звука при ведении смычка. Они накладываются друг на друга и этим
затушевывают и искажают истинную картину исследуемого приема.
Из приведенного примера видно, что даже в относительно простых задачах
непосредственное исследование объекта (процесса) часто оказывается весьма
затруднительным и не позволяет получать надежные объективные результаты. ,
Среди различных способов проверки гипотез, часто полученных и эмпирическим
путем, одним из наиболее эффективных является воспроизведение, имитация,
интересующих исследователя свойств и сторон анализируемого объекта искусственным
путем с учетом закономерностей и особенностей, установленных при предварительном
анализе. Метод этот носит название имитационное моделирование.
Так, если при исследовании мелодий какой-нибудь народности удается по
закономерностям, выявленным при анализе этих мелодий, построить (синтезировать)
новые мелодии и эти мелодии будут восприниматься как мелодии данной народности,
то тем самым подтверждается предположение о том, что выявленные закономерности
действительно определяют особенности мелодий рассмотренного вида. Заметим, что
такое подтверждение будет убедительным, если синтез осуществлялся формально, с
использованием только сформулированных предположений, и если при оценке
результатов элиминированы субъективные факторы. Если в рассмотренном случае
синтез осуществлялся не формально,, а выполнялся, например, человеком —
музыкантом, которому были сформулированы те закономерности, которые следовало
использовать при сочинении мелодии, такой метод проверки теряет свою
доказательность и становится субъективным. Это объясняется тем, что в процессе
эвристической деятельности, какой является сочинение мелодий, человек может даже
неосознанно реализовывать какие-то дополнительные закономерности, помимо
заданных. Эти дополнительные неосознанные закономерности и факторы часто могут
играть весьма существенную роль, а заданные, осознанные закономерности могут
оказаться и несущественными, что подтверждается многочисленными примерами из
разных областей творческой деятельности-человека, таких, например, как живопись,
музыка, различные игры.
В процессе анализа выявляются различные параметры — признаки или характеристики
объекта и часто эти параметры (поскольку они обнаружены в исследуемом объекте)
принимаются за существенные. На самом деле” однако, они могут быть и
несущественными — они просто не мешают этому объекту быть самим собой, не меняют
его сущности. В то же время существенные для него параметры могут оказаться
скрытыми для исследователя и не обнаруживаться при анализе
Таким образом, возникает вторая задача — установление существенности выбранных
исходных закономерностей, а также выделение среди них основных, определяющих, и
несущественных, которые либо просто не влияют, на исследуемое явление, либо
вытекают из остальных закономерностей. Решение этой задачи также может быть
осуществлено методами имитационного моделирования.
Используемые во многих творческих процессах теории и знания, как правило, имеют
интуитивный характер, не подтверждены формально, логически; так же интуитивно
устанавливаются и области применения, и способ их использования. Однако, если
эти интуитивные знания приводят к полезным результатам, то есть основания
предполагать, что они базируются на объективных закономерностях, которые, будучи
выявлены, могут лечь в основу автоматизации соответствующего творческого
процесса или, иными словами, послужить основой для его моделирования. Выявление
таких объективных закономерностей эвристических, на первый взгляд
неформализуемых процессов, каким, в частности, представляется и творчество,
осуществляется методами эвристического программирования, т. е. по существу
разновидностью имитационного моделирования.
Выше уже отмечалось, что научная ценность и объективная достоверность
результатов имитационного моделирования тем выше, .чём полнее исключены из них
субъективные факторы и чем формальнее строятся такие модели. Поэтому при решении
перечисленных задач проверки гипотез, выявления объективных существенных
закономерностей, лежащих в основе изучаемого явления или процесса, наиболее
удобно имитационное моделирование с помощью ЭВМ, называемое также математическим
моделированием
В основе математического моделирования на ЭВМ лежит математическая модель, т. е.
формальное описание известных или предполагаемых закономерностей, выявленных При
содержательном, эвристическом анализе исследуемого объекта. Модель эта
реализуется в виде машинного алгоритма, результат работы которого — описание
имитируемого процесса или исследуемого явления. При моделировании процесса
сочинения музыки, напримёр, конечный результат — нотная запись музыкального
текста и перечень тех закономерностей, которые участвовали в его синтезе.
Естественно, что ничего “своего”, не осознанного предварительно человеком,
модель и алгоритм не содержат. Критерием качества такого математического
моделирования, критерием правильности и полноты составленной модели является
степень сходства полученных на ЭВМ результатов с результатами соответствующей
человеческой деятельности. Неудовлетворительность машинных результатов
объективно доказывает неполноту или неправильность исходных посылок,
использованных при составлений и алгоритмической (программной) реализации
математической модели, и требует пересмотра исходных посылок, дополнения модели
новыми данными, т. е. совершенствования построенной модели.
При моделировании на вычислительной машине, таким образом, объективно
проверяется достаточность тех знаний, которыми; обладает машина (или, точнее,
ее: программа); для реализации изучаемого процесса или объекта. Такое
моделирование позволяет подтвердить наши Предположения, гипотезы, о механизме
исследуемого объекта или процесса, о его закономерностях, правомерность наших
представлений о структуре объекта, а также помогает установить степень его
изученности.
Составление алгоритма (машинной программы) требует формализации всех элементов и
структуры исследуемого объекта, . входящих в этот алгоритм, и тем самым
способствует логической ясности в понимании его. Непременным условием при: этом
является строгая и формальная точность определения, (раскрытия содержания) всех
понятий, вводимых в программу.
§ 1.2. Три этапа моделирования
Дифференциальный и целостный подходы при моделировании. Анализ, синтез, оценка
модели — три этапа моделирования. Способ” .оценки модели. Трудности объективной
(межличностной) оценки модели объектов художественного творчества: необходимость
специального эксперимента для преодоления психологической установки экспертов.
Цель машинного творчества — не создание шедевров.
Для моделирования существенно объединение дифференциального (атомистического) и
структурно-целостного подходов, диалектическое единство анализа и синтеза при
исследовании изучаемых явлений. Моделирование заключается в имитации изучаемого
явления. Точность имитации определяется путем сравнения полученного при
воспроизведении результата с его прототипом, объектом исследования, и оценки
степени их сходства.
В целом, моделирование включает в себя три необходимых этана: анализ объекта
исследования, построение (синтез) модели, получение результата и его оценка
.путем сравнения с объектом.
Рассмотрим более” детально эти этапы.
Анализ объекта моделирования: Выше уже отмечалось, что основу модели При ее
формировании кладутся некоторые первоначальные знания об объекте,
закономерности, устанавливающие свойства этого объекта (или класса объектов),
его характеристики, особенности связи между составляющими объект, элементами.
Получение этих знаний и их уточнение и являются содержанием первого этапа
моделирования.
На этом этапе формируется возможно более полное описание объекта: выделяются его
элементы, устанавливаются связи между ними, вычленяются существенные для
исследования характеристики, выявляются параметры, изменение которых влияет или
может влиять на объект.
На том же этапе формируются, подлежащие последующей проверке гипотезы о
закономерностях, присущих изучаемому объекту, о характере влияния на него
изменения тех или иных параметров и связей между его элементами.
На том же этапе исходные предположения переводятся на четкий однозначный язык
количественных отношений и устраняется нечеткие, неоднозначные высказывания или
определения, которые заменяются, быть может, и приближенными, но четкими,; не-
допускающими различных толкований высказываниями
Формирование (синтез) модели представляет собой второй этап моделирования. На
этом этапе в соответствии с задачами исследования осуществляется
воспроизведение, или имитация, объекта на ЭВМ с помощью программы, которая
включает в себя закономерности и другие исходные данные, полученные на этапе
анализа. Структура модели, существенно зависит от задач исследования.. Так,
например, если проверяется полнота и правильность наших знаний об объекте,
последний имитируется с использованием, всех известных исходных соотношений.
Если же задача, заключается ,в проверке некоторых предположений и степени; их
общности, то именно эти предположения вводятся в программу и в результате
имитации получаются объекты, которые лишь частично отражают -реальные свойства
имитируемого объёкта:
Оценка машинных результатов, заключается, в установлении адекватности модели и
объекта исследования — в определении степени близости,, сходства, машинных и
человеческих действий или их результатов. При этом существенно не “абсолютное
качествo” машинных результатов, а степень сходства с объектом исследования. Так,
.при моделировании музыкальных сочинений важно нe то, чтобы машинная музыка была
“лучше” музыки композиторов-классиков, а чтобы она была похожа на ту, которая
исследуется, и — в идеале — была от нее неотличима (по эмоциональности, по
выразительности, по синтаксической сложности, принадлежности к типу, стилю и т.
п.).
Успешный результат сравнения (оценки) исследуемого объекта с моделью
свидетельствует о достаточной степени изученности объекта, о правильности
принципов, положенных в основу моделирования, и о том, что алгоритм,
моделирующий объект, не содержит ошибок, т. е. о том, что созданная модель
работоспособна. Такая модель может быть использована для дальнейших более
глубоких исследований объекта в различных новых условиях, в которых реальный
объект еще не изучался.
Чаще, однако, первые результаты моделирования не удовлетворяют предъявленным
требованиям. Это означает, что по крайней мере в одной из перечисленных выше
позиций (изученность объекта, исходные принципы, алгоритм) имеются дефекты. Это
требует проведения дополнительных исследовании и соответствующего изменения
машинной программы, после чего снова повторяются второй и третий этапы.
Процедура повторяется до получения надежных результатов.
Этап оценки модели является важным этапом моделирования. В зависимости от
характера объекта исследования и поставленных задач применяются различные методы
оценки модели. Особенно большое значение имеет правильная опенка модели, когда
моделирование, используется для проверки гипотез, а также когда объекты
недостаточно формализованы и нет строгого объективного критерия сходства объекта
и модели. С подобной ситуацией часто приходится встречаться при моделировании
интеллектуальных, творческих процессов. Рассмотрим поэтому вопросы Оценки
моделей несколько более подробно.
Модельдолжна обладать существенными признаками объекта моделирования. Иначе
говоря, модель и объект должны быть неотличимы по этим признакам, которые
выбираются, вообще говоря, исследователем в зависимости от цели и. задачи
исследования. Так, чучело птицы моделирует внешний вид птицы, но не моделирует
ее динамического состояния, например полета. Самолет-орнитоптер (летательный
-аппарат с машущими, крыльями) не моделирует внешнего вида птицы, зато
моделирует ее полет. При моделировании творчества также имитируются лишь
отдельные стороны объекта, наиболее интересные (или доступные) для
исследователя.
Наличие существенных для объекта признаков в модели определяется по-разному, в
зависимости от его вида. В одних случаях эти признаки обнаруживаются
непосредственно: например, в модели гармонизации — путем отыскания ошибок, в
модели шахматиста (шахматной программе) — по результатам игры с настоящими
шахматистами. В других случаях существенные признаки оказываются “скрытыми” и
для их отыскания приходится прибегать к специальному эксперименту. Как правило,
это имеет место при оценке моделей художественных произведений.
Как известно, художественные произведения относятся к тому упомянутому выше виду
объектов, для оценки которых не существует объективных критериев. Так, одно и то
же музыкальное произведение разными критиками оценивается по-разному. И более
того, как показывает «практика, один и тот же (даже профессиональный) критик
одно и то же произведение в разное t время может оценивать тоже по-разному. На
оценку влияют разные факторы: привычка, субъективный опыт, вкус, общественное
мнение, дух. противоречия этому мнению и многие, многие другие. Весьма важна и
психологическая установка (предвзятость) по отношению к произведению, его
автору, жанру, стилю и тому подобным параметрам оцениваемого произведения.
Все вышеуказанное относится к художественным произведениям, созданным
профессиональными авторами, например композиторами-профессионалами. Проблема
значительно осложняется, когда требуется оценить машинное сочинение — стихи или
музыку. Здесь особенно ощутимо проявляется психологическая предвзятость эксперта
по отношению к. машинному творчеству. Эта предвзятость проявляется двояким
образом: либо отрицание “творческих” возможностей машины, когда эксперт, даже не
ознакомившись с машинным сочинением, не прослушав его, заранее “знает”, что
“машина не может”,либо восторженное почитание машинного творчества. Эксперты и
первого, и второго типа не могут объективно (без предвзятости) оценить машинное
сочинение, и нужен специальный эксперимент, в ходе которого их установка могла
бы быть разрушена.
Задача такого объективного в социологическом смысле эксперимента — преодоление
психологической установки экспертов по отношению к машинному творчеству
(модели), создание таких условий, чтобы они заранее не знали, оценивают ли они
человеческие произведения или их машинные модели.
Методика подобного социологического эксперимента для оценки машинной и
человеческой музыки была разработана автором (Р. X. Зарипов, 1971а). При этом
задача заключалась в получении сравнительной оценки человеком мелодий,
сочиненных профессиональными композиторами и машиной. Проблема оценки машинных
композиций и сравнения их с сочинениями композиторов может решаться только путем
опроса самих слушателей. Эта проблема связана с особенностями психологии
слушателей, воспринимающих музыку, которые не могут объективно оценить
композиции, если они .наперед знают, что, скажем, мелодия 1 — машинная, а 2 —
человеческая, подобно тому, как нельзя объективно оценить популярные, “запетые”
мелодии. Поэтому для объективного сравнения слушатели не должны знать, что они в
данный момент оценивают — машинную или человеческую музыку.
Какую же человеческую музыку следует брать для сравнения с машинными мелодиями?
Вещи несоизмеримые, несравнимые между собой, сравнивать нельзя. Так, недопустимо
мелодии песен сравнивать с монументальными- концертными произведениями вроде
симфонийили с фортепианными сонатами, а также с мелодиями из таких произведений.
Сравнивать надо композиции одинаковой структуры, одинакового объема, одинаковой
синтаксической сложности, например мелодии с мелодиями.
Для эксперимента были выбраны мелодии песен известных советских композиторов,
опубликованные в сборниках избранных песен, и мелодии, сочиненные на
вычислительной машине “Урал-2”. Все мелодии проигрывались в произвольном
порядке, неизвестном слушателям-экспертам, которые оценивали их по пятибалльной
системе и оценки записывали на бланках-протоколах. Эксперимент проводился в
разных социомузыкальных группах, в каждой из них уровень музыкальной
подготовленности участников эксперимента мог считаться примерно одинаковым. Это
были студенты Московского энергетического института, студенты Государственного
музыкально-педагогического института имени Гнесиных, участники Всесоюзного
симпозиума “Проблемы художественного восприятия”, школьники старших классов,
математики — участники методологического семинара Математического института АН
СССР имени В. А. Стеклова и Вычислительного центра АН СССР, работники
предприятий культуры . и др. Всего в эксперименте участвовало более шестисот
человек*). Кроме того, подобный “плебисцит” был проведен на основе передач по
первой программе Центрального радиовещания 25 августа 1973 г., 29 июня 1976 г. и
15 июля 1980 г.
При обработке данных эксперимента и из рассмотрения протоколов выяснилось, что
принятая методика проведения эксперимента позволила преодолеть психологическую
предвзятость, о до-торой говорилось выше: эксперты не различали, где
человеческое, а где машинное .сочинение. Не осознавая и не желая того,
большинство экспертов оценивали выше машинную музыку. В результате этого во всех
группах машинные композиции получили (по разным критериям) более высокую оценку,
чем мелодии композиторов. Вот как были оценены мелодии в такой подготовленной
аудитории, как студенты института имени Гнесиных:
Хотя эксперты не знали, какую — человеческую или машинную — музыку они
оценивают, некоторые из них высказывались довольно категорично: “Вся машинная
музыка — не музыка, нет чувства”, “Да чтобы я не отличил машинную музыку от
человеческой!”, “Много чрезмерно периодичных, туповато-машинных тем”. Но —
ирония судьбы — именно эти эксперты, не осознавая и не желая того, оценили выше
машинную музыку. Их “очевидное” представление о машинной музыке оказалось
ошибочным.
Весьма показателен в этом смысле и “плебисцит”, проведенный на основе передачи
по первой программе Центрального радиовещания 29 июня 1976 г. Цель его —
выяснить; как радиослушатели оценивают творческие возможности машин и какой они
представляют себе машинную музыку. Для этого им предложили прослушать три
мелодии и определить, кто является их автором — человек или машина. Результат,
опроса в отношении одной из мелодий был неожиданным. В своих письмах
радиослушатели отмечали, что в этой мелодии “чувствуется душа”, она “отличается
мелодичностью, пленяет слух, проникает в сердце”, что “конечно же, такую музыку
мог написать только человек”, “никакая машина не сможет заменить человека в этом
тонком творческом процессе, и не надо пытаться это делать”.
Авторы 125 писем (из 130, поступивших в редакцию) были твердо убеждены, что эта
мелодия написана композитором (только 5 человек с некоторыми оговорками
приписывали ее машине). И 125 человек из 130, хотели они этого или нет, дали тем
самым весьма высокую оценку творческим возможностям машины, показав ошибочность
своего представления о машинной музыке. А мелодию эту сочинила машина по
программе автора, описанной ниже (см. гл. 5).
Часто оказывается, что если слушатели не знают о “нечеловеческом” происхождении
музыки, то и воспринимают ее как вполне “нормальную”, не отличающуюся от
обычной. Так, на Международном совещании по искусственному интеллекту,
проходившем в городе Репино (под Ленинградом) в 1977 г., на русском и английском
языках прозвучала “ИИ-кантата” — своего рода гимн искусственному интеллекту,
сочиненный по предложению Оргкомитета совещания (рис. 2.2).
ИИ-КАНТАТА”

Рис. 2.2. Гимн искусственному интеллекту.
Слова написал А. Аверкин, а музыка была сочинена на машине “Урал-2” по
программе, описанной в книге Р. X. Зарипова (1971а). Исполненная в
непринужденной обстановке оркестром и певцами, эта песня была воспринята как
обычное музыкальное произведение, и не все участники совещания сразу поверили,
что — музыку этого гимна сочинила машина*).
Результаты этого эксперимента, проведенного многократно, подтверждают следующий
факт: при моделировании на ЭВМ таких форм музыкального творчества, как сочинение
мелодий массовых песен, получены машинные результаты, которые не -только
соизмеримы с человеческими, но в ряде случаев превосходят последние по качеству.
Это позволяет судить о высокой степени изученности механизма порождения таких
мелодий и подтверждает правильность выбранных принципов моделирования.
Этот эксперимент представляет собой реализацию идеи Тьюринга об испытании на
интеллектуальность (“игре в имитацию”)
ИИ-КАНТАТА
Музыка ЭВМ “Урал-2” Слова А. Аверкина
Вас встречает Решино —
Тут простор мечтам.
Интеллект искусственный
Мудр не по летам.
Диалог с программами,
ЭВМ с экранами,
Шимпанзе с бананами
Мы покажем вам.
Припев:
Искусственный интеллект
Стал теперь проблемой века.
С искусственным интеллектом
Мы прославим человека. ;
Нам читают лекции
Главные спецы —
Всех систем искусственных
Деды и отцы.
Фреймы и сценарии
Внукам мы оставили,
Пусть в них разбираются
Наши молодцы.
Припев
Мы ведем дискуссии,
За окном весна —
И модель без этого
Будет не полна. .
Пусть там ходят роботы
И качают хоботом. Мы же кубок дружеский
Осушим до дна.
Припев
AI-CANTATA
Music: Computer “Ural-2” Text: A. Averkin
We meet. you in Repino — Hope, well be kind. •Artificial Intelligence Has a
plastic mind, Look at machines conversation, Robots travel simulation, Monkey in
logic of action And what else youll find.
Refrain:
Artificial Intelligence!
It became the greatest problem.
Artificial Intelligence!
It glorifies Homo Sapiens.
At the joint conference There are experts — Of every system intellect Dadies and
granddads. Frames and scripts in memory We present to our children, Now they are
studied by Our progeny.
Refrain
Were discussing Robotics. Outside its spring, Add spring to your Theory — It
will be complete. Let it. be the robots peace With a swinging proboscis. Well
empty a frendly glass And then we shall sing.
Refrain
применительно к музыке. Тьюринг (А. Тьюринг, 1960) предложил судить о наличии
“интеллекта” по результатам “игры в имитацию”, которая сводится к следующему. В
игре участвуют некое лицо (эксперт) и две системы А и В, одна из которых —
человек, а другая — машина; Эксперт, не видя этих систем, задает любые вопросы
системам А и В и, анализируя их ответы, должен определить, какая из них является
машиной. Если он не сможет, определить этого в течение заданного временив то
такая машина считается “интеллектуальной”.
Из результата упомянутого выше эксперимента следует; что программа-композитор,
синтезирующая эти мелодии, выдерживает тест Тьюринга.
Нужно отметить, что мелодии композиторов в эксперименте — независимо от та
качества или: отношения к ним слушателей — являются результатом той
профессиональной деятельности-человека, которую принято называть творчеством.
Здесь имеется в виду, что продукты художественного творчества — это не только
мировые шедевры искусства: Седьмая (“Ленинградская”) симфония Д. Шостаковича в
интерпретации Е. Мравинского, “Вариации на тему рококо” П. Чайковского в
исполнении Д. Шафрана, романс “Я помню чудное мгновенье” М. Глинки в исполнении
И. Козловского и. т. п., но и многие тысячи другихпроизведений. Поэтому не
следует нигилистически отмахиваться от тех продуктов художественного творчества,
которые по тем или иным причинам не стали шедеврами или просто популярными, ибо
причина популярности художественного произведения — особая проблема, не
изученная до настоящего времени.
Практика проведения упомянутого выше эксперимента показывает, что понятие,
продукта художественного творчества ассоциируется у слушателей преимущественно
(за редким исключением) лишь с популярными произведениями, наиболее им
знакомыми. И даже более того — не столько с популярными, сколько с наиболее
значительными по их эстетическим качествам, можно сказать, в некотором смысле —
с шедеврами мирового искусства. Ведь нередки случаи снисходительного отношения
даже к творчеству оригинальнейших композиторов, создавших, например, эпоху в
советской песне. .
У композитора — члена Союза композиторов СССР — высокий уровень профессионализма
и мастерства; у композитора, окончившего консерваторию (и не только Московскую),
— тоже достаточно высокий уровень, чтобы произведения его» могли быть эталоном в
подобном эксперименте. Ведь мелодия такого композитора обязательно включает в
себя элементы профессионализма. Студенты на учебных занятиях “набивают руку” в
технике и впоследствии используют эти навыки в своей творческой практике уже
автомагически. Все это особенно ощутимо проявляется в тонкостях, в деталях, что,
собственно, и отличает профессионала от дилетанта, от самодеятельного сочинителя
музыки. Композитор-профессионал просто уже органически не может писать как
дилетант, ибо он приучен или привык писать профессионально. (Чтобы предостеречь
очевидные возражения, следует сразу же оговориться: здесь имеются в виду общие
правила, а не возможные исключения из них.) Таким образом, эксперимент помогает
оценить степень “профессионализма” в машинной музыке, а отнюдь не степень ее
“художественности”.
Остановимся теперь на высказываниях некоторых участников эксперимента о том, что
мелодии композиторов, использованные в эксперименте, серые и бездарные, и только
поэтому машинные мелодии получили более высокую оценку. Авторы этих
высказываний, находясь под гнетом установки “машина не может”, забывают, что
задача заключается пока не в машинном создании шедевров или произведений
искусства, а прежде всего в выявлении закономерностей музыкальных композиций как
результата творческого процесса д в их машинном воспроизведении. Кроме того,
проблема заключается и в способе отыскания объективных (межличностных) критериев
оценки продуктов художественного творчества.
Оппонентам трудно изменить установку, отношение к понятию художественного
творчества. Следует, однако, помнить что знакомые многим, а тем более любимые
произведения, это лишь малая часть — капля .в океане того, что создается в
результате художественного творчества. А все остальные произведения — как это ни
печально и ни горько для их авторов — остаются безвестными и часто никогда и
никем не исполняются, но от этого они не перестают быть продуктами
художественного творчества. Здесь часто происходит терминологическая путаница.
Понятие о продукте (или результате) художественного творчества необоснованно
смешивается с понятием о произведении искусства, к которому предъявляются
повышенные эстетические требования, а эту тонкость в понятиях, очевидно, не все
улавливают.
Аналогичная ситуация имеет место ив других видах художественного творчества.
§ 1.3. Синтезирование — частный случаи моделирования
Синтезирование и моделирование. Синтезирование в музыке.
Выше уже отмечалось, что один из этапов моделирования — синтез, построение
модели и воспроизведение результата функционирования этой модели (синтез
результата). В общем случае такое синтезирование не является самоцелью, а служит
для последующего„сравнения модели с оригиналом, в результате которого
проверяется соответствующая теория и гипотеза;
Бывают, однако, случаи, когда цель экспериментов — синтезирование нового, и
тогда сходства с оригиналом не требуется;
больше того, оно может оказаться нежелательным. Так, средства электронного
синтеза — электромузыкальные инструменты — позволяют получать тембры, как
имитирующие классические музыкальные инструменты (скрипка, кларнет, рояль и т.
п.), так и новые, неизвестные в музыкальной практике. В первом случае происходит
моделирование известных тембров, во втором более уместно говорить .просто о
синтезировании новых тембров. Очевидно, что первое значительно труднее — ведь
для этого надо знать количественные характеристики звучания инструментов.
Другой пример. Моделирование и синтезирование (сочинение) музыки имеют между
собой много общего и внешне вроде бы не отличаются друг от друга: ведь
результатом как моделирования, так и сочинения (синтезирования) музыки на
вычислительной машине служат музыкальные композиции — музыкальные пьесы,
записанные в виде обычной нотации. Однако моделирование музыки не сводится к
синтезированию (сочинению) музыки. Для моделирования необходима знать параметры
имитируемого объекта тогда как просто для синтезирования этого не требуется, —
любой произвольный набор параметров синтезирует обязательно что-то, но не
моделирует. Таким образом, моделирование и собственно синтезирование (сочинение)
имеют разные цели, разные задачи. Иначе говоря, моделирование — это
синтезирование с последующей оценкой сходства модели и оригинала.
Первые опыты сочинения машинной музыки появились в конце пятидесятых годов и
были посвящены моделированию музыки (в основном — мелодий) традиционной
структуры. Позднее к машине обратились композиторы. Моделирование музыки, более
пригодное для исследовательских работ, оказалось малоэффективным для получения
Практических результатов при сочинении профессиональной музыки. Поэтому
композиторы стали использовать машину лишь в качестве помощника для выполнения-
рутинной части творческого процесса.
Уже упомянутая выше сложность постановки объективного эксперимента при
моделировании музыкальных объектов привела на Западе к тому, что исследователи
постепенно стали переходить от идеи моделирования (в первых экспериментах; см. о
них в обзорной части книги: Р. X. Зарипов, 1971а) к значительно легче
осуществимой идее синтезирования музыки, структура которой существенно
отличается от ранее известной музыкальной структуры. Это же, по существу,
признает в своем обзоре об использовании ЭВМ при сочинении музыки и американский
композитор Хиллер (Хиллер, 1970), называющий мелодии традиционной структуры
(мелодии массовых песен) народными мелодиями (folk-tunes).
В новых же музыкальных системах последовательности нот образуются на основании
правил, вводимых композитором умозрительно, без какой-либо связи с традиционными
структурами, известными музыкальной практике, — так появляется
конструктивистская система.
При сочинении такой музыки использование вычислительных машин оказалось очень
удобным для получения различных вариантов звуковых сочетаний, из которых
композитор выбирает подходящие по своему усмотрению. Таким образом, машина
используется для производства заготовок, черновых вариантов звуковых сочетаний.
Синтезирование огромного количества возможных вариантов таких сочетаний вручную
весьма затруднительно и требует большого времени и кропотливого, отнюдь не
творческого труда. Кроме того, те сочетания (лишь весьма малая доля
из всех возможных), которые композитор получает вручную, часто плохо подходят
для выражения творческого замысла. Нужны талант большого мастера и огромная
творческая интуиция, чтобы среди множества потенциально возможных комбинаций
увидеть (или точнее — .услышать) комбинацию подходящую, созвучную задуманной
идее. Эта задана подобна проблеме “видения” мелодии темы для написания фуги —
особой формы полифонического произведения. Как известно, не любая наперед
заданная мелодия годится в качестве темы для сочинения фуги. Об этом можно
судить хотя бы по следующему высказыванию С. С. Скребкова:“…путь, исходящий из
предварительного сочинения всей темы целиком, заведомо связан со случайностью и
ни в коей мере не гарантирует успеха” (С. С. Скребков, .1951, с. 223). И лишь
вы- . дающиеся мастера полифонического искусства могут интуитивно чувствовать,
пригодна ли данная мелодия для полифонической (и, в частности, канонической)
разработки (см., например, Е.Корчинский, 1960).
Мысль о применении вычислительных машин для изготовле-ния заготовок в
поэтическом творчестве (например, составление заготовок рифм или полного словаря
русских рифм, включая и классические точные, и современные неточные рифмы) не
раз высказываласьи в нашей печати (см., например, С.Л Соболев, 1963;
А.М.Кондратов, 1963).
Перебор возможных вариантов (и, следовательно, их подготовка или сочинение)
занимает большое место в различных видах творчества — художественном,
изобразительном или научном.
Разработка методов комбинирования звуков для получения соответствующих заготовок
музыкальных фраз имеет большую историю. Этим, например, занимался ещё в XVII
веке французский теоретик музыки Марен Мерсенн (Куме, 1972). В своих музыкальных
трактатах Мерсенн часто иллюстрирует изложение численными примерами, в
частности, из области элементарной комбинаторики. Так, например, Мерсенн изучал
закономерности структуры 8!= 40320 “песен” — мелодии из восьми нот (высот звуков
с одинаковыми длительностями), полученных в результате перестановок. Его
интересовали правила искусства комбинировать, которые бы помогли композиторам
“делать хорошие песни”, поскольку он устанавливал связи .выразительных
музыкальных средств и приемов композиции с определенными эмоциями.
По-видимому, в стихотворном творчестве — машина еще не использовалась для
производства заготовок поэтических элементов. В музыке же эта идея оказалась
весьма плодотворной. Она реализована в творчестве таких, например, композиторов
нетрадиционного направления, как Я. Ксенакис, П. Барбо (А. Моль, 1975), Р.
Ружичка (1972, 1980), Л. Аствацатрян (1977) и др.
Использование машинных заготовок пригодно и для получения сочинений традиционной
музыкальной системы. На рис. 2.3 приведена музыкальная пьеса, сочиненная
итальянским математиком и музыкантом Гальярдо и названная им “Русской песней”.
Мелодия целиком составлена из заготовок, в качестве которых были использованы
отрывки (в основном однотактовые) мелодий, сочиненных ЭВМ “Урал-2” по программе
автора этой книги (Р. X. Зарипов, 1971а). Аккомпанемент составлен формальным
способом в соответствии с музыкальной теорией, разработанной Гальярдо (Гальярдо,
Форназари, 1978).
Э. Гальярдо. Русская песня

Рис, 2.3. Музыкальная пьеса, сочиненная Гальярдо, как пример сотрудничества
человека и ЭВМ.
Существует мнение, которое можно услышать даже от некоторых специалистов по
моделированию на ЭВМ, что если заставить машину долго работать по довольно
простой программе, сочиняющей мелодии,, то можно получить и превосходные мелодии
как результат случайного сочетания звуков. Подобная гипотетическая ситуация была
рассмотрена еще «французским математик ком Э. Борелём в его книге “Случай”, где
речь шла о миллионе обезьян, печатающих на пишущих машинках тексты наугад, и о
вероятности того, что таким путем могут быть получены всевозможные книги,
хранящиеся в крупнейших библиотеках, мира.
Такой способ может быть полезен для получения практических результатов при
сочинении профессиональной музыки, и он используется, как уже было сказано выше,
некоторыми композиторами — это метод заготовок вариантов различных фрагментов
музыки. Полученные машиной варианты требуют отбора, который производится
композитором, — наиболее удачные сочетания он включает в свое произведение. Как
и для всякой человеко-машинной системы, этот метод применим для повышения
эффективности при получении практических результатов. Для осознания же
исследуемого процесса, осознания каждого его этапа более пригоден такой метод
моделирования, при котором конечный результат получаетсямашиной без
вмешательства человека и где контролируется каждый шаг работы машины.
§ 1.4. Трудности моделирования творческой деятельности
Принципиальные трудности моделирования интуитивной деятельности. Машине трудно
то, что человеку, легко. Продуктивная деятельность — пример большой системы.
Соблазн создания сложной модели.
Здесь пойдет речь не о тех технических трудностях моделирования творческой
деятельности, которые связаны с недостаточным вниманием к этому кругу проблем
или с затруднениями по практическому использованию вычислительных машин
специалистами гуманитарного профиля (музыкантами, традиционными психологами,
литераторами и т. д.). И даже не о тех- препятствиях, которые ставят развитию
работ по моделированию творчества и искусственному интеллекту некоторые авторы,
считающие, что создание искусственного разума есть миф, отнимающий известное
количество сил и средств и отвлекающий кибернетику от решения ее прямых задач.
Такого рода трудности и препятствия, разумеется, сильно тормозят развитие этих
работ. Однако, не являясь принципиальными, они рано Или поздно будут преодолены.
Здесь уместно напомнить высказывание И. А. Полетаева (И. А. Полетаев, 1971):
“Невозможно выключить “рубильник науки”. Нельзя прекратить исследования
генетического анализа и синтеза, нельзя закрыть Америку. Если человек может
открыть Америку, полететь на Луну, синтезировать живое существо, построить
мыслящее механическое чудовище, он непременно и неизбежно все это сделает, даже
если его не побуждает к этому прямая нужда. Просто — таков человек! Почему он
таков — мы не знаем, но узнаем, ибо человек (не этот, так следующий) и это
узнать не побоится”.
В этом параграфе будут рассмотрены некоторые принципиальные трудности, связанные
со спецификой таких объектов моделирования, как интеллектуальные процессы и
творческая деятельность. Основная трудность, видимо, заключается в недостаточной
изученности (скорее — в полной неизученности) закономерностей механизма
интуиции, лежащего в основе этой деятельности.
С этим же связана и недостаточная изученность проблемы понимания в .широком
смысле, когда имеется в виду не только понимание в диалоге, но и понимание,
осознание целей и результатов интеллектуальной деятельности. Отсюда следует и
практическая трудность в моделировании творческих процессов (эвристической
деятельности и психических функций), заключающаяся в необходимости отыскания и
формализации тех элементов творческого процесса, которые свободно и неосознанно
реализует человек. В процессе творческой деятельности при решении различных
задач человек обычно не разлагает процесс отыскания решения на элементарные
операции, содержащиеся в нем, реализуя многие из них. неосознанно и
автоматически. Так, он не задумывается, по каким формальным признакам он
практически безошибочно отличает на фотографии мужчину от женщины, узнает своих
знакомых по внешнему виду, или, разговаривая по телефону, по голосу, успешно
выделяя их из множества других людей. Так же неосознанно мы безошибочно отличаем
грузинскую . мелодию от русской, хотя и не сможем объяснить, каким образом.
Любопытно, что это безошибочно делают и те, кто не обладает даже минимальными
познаниями в музыке *).
Для алгоритмизации же и для моделирования на электронной вычислительной машине
подобных процессов необходимо внести в программу все сведения об объекте,
формализовать все те операции, которые человек обычно совершает интуитивно.
Машине необходимо точно и однозначно сообщить все детали и уточнения, все те
сведения об объекте исследования, которые на самом деле важны, существенны для
успешного решения задачи. В противном случае результат моделирования будет лишен
характерных черт исследуемого объекта и будет неадекватен оригиналу.
Существенной трудностью машинного моделирования является также и то, что в силу
различия особенностей функционирования машины и человека целый ряд задач,
трудных для человека, легко решается машиной, а многие задачи, с которыми
человек расправляетсяшутя, с большим трудом решаются на машине. Так, человек
легко читает даже незнакомый почерк — машина, несмотря на многолетнюю упорную
работу в этом направлении многих научных коллективов как в нашей стране, так и
за рубежом (В. С. Переверзев-Орлов, 1976), пока этого делать не умеет.
Зато, например, при разложении иррационального числа 2 в бесконечную цепную
дробь {А. Н. Хованский, 1956) современная электронная вычислительная машина за
считанные минуты позволяет получить несколько тысяч неполных частных а1 (а, —
целые положительные числа, i=i, 2, ,..), тогда как необходимость оперировать с
большими числами служит препятствием при вычислении вручную даже нескольких
десятков величин а,. При получении одной тысячи элементов a, Ct=l, 2, …
…,1000) приходится в промежуточных выкладках иметь дело с числами порядка 10″,
где а примерно равно двум-трем тысячам. Такое число очень велико, и если
выписать подряд все его цифры, то оно вряд ли уместится на одной странице
печатного текста. И эти числа надо многократно складывать и делить одно на
другое.
С аналогичной трудностью встречаются и в музыкальном творчестве. Человек,
никогда не обучавшийся музыкальной грамоте, легко может придумать мелодию на
заданные стихи — сочинить песню. (Это очень ловко делают даже дети в детском
саду.) Составить же программу, по которой бы машина сочиняла мелодии такой же
сложности (такой синтаксической структуры), — дело очень трудное. Здесь у
человека проявляется интуиция. подражания — ведь он сочиняет песню на основе
своего прошлого опыта, приобретенного им в качестве слушателя. По-видимому,
человек, Никогда не слышавший песен, не сможет и сочинить никакой мелодии.
С другой стороны, как показывает практика, гармонизовать мелодию (что делают на
занятиях по курсу гармонии в музыкальных училищах или в консерватории)
значительно труднее, чем сочинить мелодию. Гармонизация мелодии в общих чертах
(на первом этапе обучения) заключается в следующем. Задается мелодия в виде
последовательности нот. К каждой ноте мелодии надо подобрать соответствующий
аккорд, представляющий собой упорядоченный набор четырех звуков (или голосов,
имеющих следующие названия: сопрано, альт, тенор, бас). При этом соединение
аккордов осуществляется по определенным принципам и правилам, выработанным
художественной практикой. Гармонизация мелодии требует знания многих
специфических правил и рационального, осознанного применения их при решении
таких задач. Интуиция здесь, как правило, не помогает. Составить же программу
для вычислительной машины, которая бы хорошо решала задачи по гармонизации,
намного легче, чем составить программу для сочинения хороших мелодий*).
Разные задачи человек решает по-разному, и ему не все равно, как он это делает —
осознанно или неосознанно — путем вычислений, расчетов, сравнений или
интуитивно, без всяких вычислений. Человеку легче решать задачи без вычислений —
например, задачи на подражание, узнавание или распознавание образов. Для того
же, чтобы такие, задачи решались на машине, ей нужен алгоритм — система
однозначных и точных предписаний, далеко не всегда известная человеку.
Говоря о трудностях такого рода при моделировании жизненных процессов, И. А.
Полетаев в одном из своих выступлений (на конференции “Математическое
моделирование жизненных процессов”, Москва, 17 — 18 марта .1966 г.) сказал:
“Если хотите убедиться, что вы плохой специалист (психолог, биолог, социолог и
т. п.), попытайтесь сделать хорошую модель Увидите, как вы» плохо знаете
предмет”.
Сложная деятельность (психическая, эвристическая, продуктивная) внешне часто
представляется простой лишь потому, что в ней незаметно, не обнаруживая «себя,
вступает в действие механизм интуиции — подражания- или. узнавания, до сих пор
изученный очень слабо. Простой же эта деятельность кажется из-за того, что в ней
используется мало правил, либо их вообще нет (как при узнавании друзей по их
голосам). Но правила всегда нужно применять осознанно — по ним надо вычислять, а
это — неестественное и некомфортное занятие для человека. Поэтому они всегда
заметны, и чем меньше правил используется в продуктивной (эвристической)
деятельности человека, тем она кажется ему проще и легче.
И лишь при построении модели такой деятельности, при ее формализации и машинном
моделировании выясняется, как мало мы о ней знаем и как много делается по
интуиции при ее ручной, или субъективной реализации.
Воспроизводя (моделируя) объект исследования и совершенствуя его модель, мы шаг
за шагом проникаем в суть объекта., познаем его существенные, характерные
свойства, попутно убеждаясь в несущественности других его свойств или признаков
(которые прежде казались существенными). Говоря образно, мы можем до конца
понять лишь тот мир, который строим сами.
Специфика самого метода моделирования на ЭВМ и рассмотренные выше трудности
моделирования требуют на первых порах . ограничиваться наиболее простыми
синтаксическими структурами объекта исследования для выявления принципиальных,
наиболее существенных сторон как самого метода моделирования, так и изучаемого
объекта. В этом тоже заключена определенная трудность, так как при исследовании
какого-либо объекта с помощью электронной вычислительной машины, как показывает
практика, всегда есть большой соблазн сразу же получить сложный машинный
результат. В данном же случае поддаться соблазну — не лучший способ его
преодолеть.
Так, при моделировании музыкальных сочинений некоторые программисты, не имея
предварительной подготовки в исследовании музыки, начинали моделирование с
вальсов Штрауса. Это очень сложная структура, особенно для начинающих, поэтому
неудивительно, что все их попытки (без исключения) постигла неудача: ни в одном
случае не было даже закончено составление программы. Наступившее разочарование
навсегда отбило у авторов этих программ охоту заниматься подобным делом.
Как показывает опыт моделирования сложных систем, целесообразнее начинать
исследовать не весь объект в целом, не всю сложную систему, а его фрагменты,
отдельные его стороны или явления, т. е. строить эскизные модели объекта. Все
это на первых этапах неизбежно приводит к схематизации, определенному
упрощенчеству (часто намеренному, сознательному) в постановке и решении задач,
но позволяет получить полезные результаты и использовать их при решении более
сложных задач.

Содержание

1. Перечислите основные направления дальнейшего развития САПР

2. Опишите устройства ввода-вывода информации ЭВМ

3. Опишите состав лингвистического обеспечения САПР. Подробно остановитесь на диалоговых языках

Список используемой литературы

1. Перечислите основные направления дальнейшего развития САПР

Система автоматизированного проектирования (САПР, в англоязычном написании CAD System — Computer Aided Design System) — это система, реализующая проектирование, при котором все проектные решения или их часть получают путем взаимодействия человека и ЭВМ.

В настоящий момент существует несколько классификационных подгрупп, из них три основных: машиностроительные САПР (MCAD — Mechanical Computer Aided Design), архитектурно-строительные САПР (CAD/AEC — Architectural, Engineering, and Construction), САПР печатных плат (ECAD — Electronic CAD/EDA — Electronic Design Automation). Наиболее развитым среди них является рынок MCAD, по сравнению с которым секторы ECAD и CAD/AEC довольно статичны и развиваются слабо. Рассмотрим процесс развития автоматизированного проектирования в машиностроении.

Современный рынок машиностроения предъявляет все более жесткие требования к срокам и стоимости проектных работ. Проведение конструкторских работ, нацеленных на создание качественной, конкурентоспособной продукции, связано с подготовкой точных математических моделей узлов и агрегатов, а также с выполнением огромного объема математических расчетов, необходимых для инженерного анализа конструкций. Основной путь повышения конкурентоспособности предприятия связан с резким сокращением сроков создания моделей и ускорением расчетов математических параметров на всех этапах разработки продукции. Таким образом, применение высокопроизводительных систем автоматизированного проектирования, технологической подготовки производства и инженерного анализа (CAE/CAD/CAM-систем) стало ключевым элементом бизнеса предприятия, работающего на современном рынке машиностроения.

САПР на базе подсистемы машинной графики и геометрического моделирования (собственно CAD — Computer Aided Design) решают задачи, в которых основной процедурой проектирования является создание геометрической модели, поскольку любые предметы описываются в первую очередь геометрическими параметрами.

САПР системы технологической подготовки производства (CAM — Сomputer Aided Manufacturing) осуществляют проектирование технологических процессов, синтеза программ для оборудования с ЧПУ, моделирование механической обработки и т.п. в соответствии с созданной геометрической моделью.

САПР системы инженерного анализа (CAE — Computer Aided Engineering) позволяют анализировать, моделировать или оптимизировать механические, температурные, магнитные и иные физические характеристики разрабатываемых моделей, проводить симуляцию различных условий и нагрузок на детали.

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

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

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

Постпроцессор служит для визуализации результатов решения в удобной для пользователя форме. В машиностроительных САПР это форма — графическая. Конструктор может анализировать поля напряжений, температур, потенциалов и т.п. в виде цветных изображений, где цвет отдельных участков характеризует значения анализируемых параметров.

Наконец, системы управления инженерными данными (PDM — Product Data Management) обеспечивают хранение и управление проектно-конструкторской документацией разрабатываемых изделий, ведение изменений в документации, сохранение истории этих изменений и т. п.

На первом этапе развития возможности систем в значительной мере определялись характеристиками имевшихся в то время недостаточно развитых аппаратных средств ЭВМ. Для работы с системами САПР использовались графические терминалы, подключаемые к мэйнфреймам. Процесс конструирования механических изделий заключается в определении геометрии будущего изделия, поэтому история CAD-систем практически началась с создания первой графической станции. Такая станция Sketchpad, появившаяся в 1963 г, использовала дисплей и световое перо. Ее создатель И. Сазерленд в дальнейшем работал в агентстве ARPA и возглавлял департамент анализа и обработки информации, а позже стал профессором Гарвардского университета.

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

В 1977 г. ACM представила документ Core, который описывал требования к аппаратно-независимым программным средствам. В 1982 г. появилась система Graphical Kernel System (GKS), принятая в качестве стандарта в 1985 г, а уже в 1987 г. был разработан вариант GKS-3D с ориентацией на 3D-графику.

Параллельно с развитием CAD-систем бурное развитие получили CAM-системы автоматизации технологической подготовки производства. В 1961 г. был создан язык программирования APT (Automatic Programming Tools), впоследствии этот язык стал основой многих других языков программирования применительно к оборудованию с числовым программным управлением. Параллельно с работами, проводившимися в США, в СССР Г.К. Горанский создал первые программы для расчетов режимов резания.

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

В 1965 г. NASA для поддержки проектов, связанных с космическими исследованиями, поставила задачу разработки конечно-элементного программного пакета. К 1970 г. такой пакет под названием NASTRAN (NAsa STRuctural ANalysis) был создан и введен в эксплуатацию. Стоимость разработки, длившейся 5 лет, составила $4 млн. Среди компаний, участвовавших в разработке, была MSC (MacNeal-Schwendler Corporation), которая с 1973 г. начала самостоятельно развивать пакет MSC.NASTRAN, впоследствии ставший мировым лидером в своем классе продуктов. С 1999 г. компания MSC называется MSC.Software Corporation. В 1976 г. был разработан программный комплекс анализа ударно-контактных взаимодействий деформируемых структур DYNA-3D (позднее названный LS-DYNA).

Мировым лидером среди программ анализа на макроуровне считается комплекс Adams (Automatic Dynamic Analysis of Mechanical Systems), разработанный и совершенствуемый компанией Mechanical Dynamics Inc. (MDI). Компания создана в 1977 г. Основное назначение комплекса Adams — кинематический и динамический анализ механических систем с автоматическим формированием и решением уравнений движения.

Широкое внедрение систем САПР в то время сдерживалось высокой стоимостью программных продуктов и «железа». Так, в начале 80-х годов прошлого века стоимость одной лицензии CAD-системы доходила до $100000 и требовала использования дорогостоящей аппаратной платформы.

Следующий этап развития ознаменовался началом использования графических рабочих станций под управлением ОС Unix. В середине 80-х годов компании Sun Microsystems и Intergraph предложили рабочие и графические станции с архитектурой SPARC. Фирма DEC разработала автоматизированные рабочие места на компьютерах VAX, появились персональные компьютеры на основе процессоров i8086 и i80286. Эти разработки позволили снизить стоимость CAD-лицензии до $20000 и создали условия более широкого применения для CAD/CAM/CAE-систем.

В этот период математический аппарат плоского геометрического моделирования был хорошо «доведен», способствуя развитию плоских CAD-систем и обеспечивая точность геометрии до 0,001 мм в метровых диапазонах при использовании 16-битной математики. Появление 32-разрядных процессоров полностью обеспечило потребности плоских CAD-систем для решения задач любого масштаба.

Развитие CAD-систем следовало двум подходам к плоскому моделированию, которые получили название твердотельный и чертежный. Чертежный подход оперирует такими основными инструментами как отрезки, дуги, полилинии и кривые. Операциями моделирования на их основе являются продление, обрезка и соединение. В твердотельном подходе основными инструментами являются замкнутые контуры, а остальные элементы играют вспомогательную роль. Главными операциями моделирования являются булевы объединение, дополнение, пересечение.

В 80-е годы прошлого века характеристики использовавшегося для САПР вычислительного оборудования значительно различались. Аппаратной платформой CAD/CAM-систем верхнего уровня были дорогие высокопроизводительные рабочие станции с ОС Unix. Такая техника позволяла выполнять сложные операции как твердотельного, так и поверхностного объемного моделирования применительно к деталям и сборочным узлам из многих деталей. Идеология систем объемного моделирования базируется на объемной мастер-модели; при этом определяется геометрия поверхности не по проекциям отдельных сечений, а интегрально — для всей спроектированной поверхности. Используя модель, можно получить информацию о координатах любой точки на поверхности, а также сформировать плоские изображения: виды, сечения и разрезы. Геометрическая модель позволяет легко получить такие локальные характеристики как нормали, кривизны и интегральные характеристики — массу, объем, площадь поверхности, момент инерции.

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

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

Принято делить CAD/CAM-системы по их функциональным характеристикам на три уровня (верхний, средний и нижний). В 80-е годы прошлого века такое деление основывалось на значительном различии характеристик использовавшегося для САПР вычислительного оборудования. CAD-системы нижнего уровня предназначались только для автоматизации чертежных работ, выполнявшихся на низкопроизводительных рабочих станциях и персональных компьютерах.

К 1982 г. твердотельное моделирование начали применять в своих продуктах компании IBM, Computervision, Prime, но методы получения моделей тел сложной формы не были развиты, отсутствовал аппарат поверхностного моделирования. В 1983 г. была разработана техника создания 3D-моделей с показом или удалением скрытых линий. В 1986 г. компания Autodesk выпустила свой первый CAD-продукт Autocad — однопользовательскую версию на языке «C» с поддержкой формата IGES. В области автоматизации проектирования унификация основных операций геометрического моделирования привела к созданию универсальных геометрических ядер, предназначенных для применения в разных САПР. Распространение получили два геометрических ядра: Parasolid (продукт фирмы Unigraphics Solutions) и ACIS (компания-разработчик Spatial Technology). Ядро Parasolid было разработано в 1988 г. и в следующем году стало ядром твердотельного моделирования для CAD/CAM Unigraphics, а с 1996 г. — промышленным стандартом.

Необходимость обмена данными между различными системами на различных этапах разработки продукции способствовала стандартизации описаний геометрических моделей. Вначале появился стандарт IGES (Initial Graphics Exchange Specification). Фирма Autodesk в своих продуктах стала использовать формат DXF (Autocad Data eXchange Format). Затем были разработаны язык Express и прикладные протоколы AP203 и AP214 в группе стандартов ISO 10303 STEP (Standard for Exchange Product Model Data). В 1986 г. появился ряд новых стандартов. Среди них CGI (Computer Graphics Interface) и PHIGS P (Programmer’s Hierarchical Interactive Graphics System) — стандарт ANSI, принятый в качестве стандарта ISO в 1989 г. В 1993 г. компанией Silicon Graphics предложен стандарт OpenGL (SGI Graphical Language), широко используемый в настоящее время.

В упомянутых системах используются графические форматы для обмена данными, представляющие собой описание изображения в функциях виртуального графического устройства (в терминах примитивов и атрибутов). Графический формат (метафайл) обеспечивает возможность запоминания графической информации, передачи ее между различными системами и интерпретации для вывода на различные устройства. Такими форматами явились CGM — Computer Graphics Metafile, PostScript — Adobe Systems Language, GEM — GEM Draw File Format и др.

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

Примерами CAD/CAM-систем верхнего уровня являются Unigraphics (UGS, первый вариант разработан в 1975 г.), CATIA (компания Dassault Systemes, 1981 г.), Pro/Engineer (PTC, 1987 г.). К числу САПР верхнего уровня в 90-е годы относились также EUCLID3 (Matra Datavision), I-DEAS (SDRC), CADDS5 (Computervision), но их развитие было прекращено в связи со слиянием компаний. Еще раньше система CADDS5 была приобретена компанией PTC (Parametric Technology Corp.). Эта компания, штаб-квартира которой расположена в США, была основана в 1985 г. бывшим профессором Ленинградского университета Семеном Гейзбергом.

Третий этап развития начинается развитием микропроцессоров, что привело к возможности использования CAD/CAM-систем верхнего уровня на персональных ЭВМ. Это заметно снизило стоимость внедрения САПР на предприятиях. Рабочие станции на платформе Windows — Intel не уступали Unix-станциям по функциональности и многократно превосходят последние по объемам продаж. Стоимость лицензии снизилась до нескольких тысяч долларов. В 1992 г. корпорация Intergraph, один из ведущих на тот момент производителей CAD-систем для машиностроения, приняла решение о разработке нового программного продукта, целиком построенного на базе платформы Windows — Intel. В результате в конце 1995 г. появилась система геометрического моделирования Solid Edge. В 1993 г. в США была создана компания Solidworks Corporation и уже через два года она представила свой первый пакет твердотельного параметрического моделирования Solidworks на базе геометрического ядра Parasolid. В 1998 г. к Unigraphics перешло все отделение Intergraph, занимавшееся САПР для машиностроения. В это же время Solid Edge сменила геометрическое ядро ACIS на ядро Parasolid. В 1999 г. появилась шестая версия Solid Edge на русском языке. Временные затраты на разработку крупнейших интегрированных CAD/CAM решений превысили 2000 человеко-лет.

Ряд CAD/CAM систем среднего и нижнего уровней был разработан в СССР и России. Наибольшее распространение среди них получили Компас (компания Аскон) и T-Flex CAD (Топ Системы) и некоторые другие.

Четвертый этап (начиная с конца 90-х годов) характеризуется интеграцией CAD/CAM/CAE-систем с системами управления проектными данными PDM и с другими средствами информационной поддержки изделий.

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

Сложность управления проектными данными, необходимость поддержания их полноты, достоверности и целостности, необходимость управления параллельной разработкой привели в 80-е годы к созданию системам управления проектными данными PDM (Product Data Management).

В начале 80-х годов компания CDC разработала первую PDM-систему под названием EDL. В 90-х годах активно разрабатывались продукты PDM для САПР в машиностроении. Одной из первых развитых PDM-систем являлась система Optegra компании Computervision. В этот же период компания Unigraphics Solutions (UGS) совместно с Kodak разработала PDM-систему iMAN. В 1998 г. компания PTC вышла на рынок PDM-систем, купив компанию Computervision и ее Internet-ориентированную PDM-технологию Windchill. В последние годы происходило быстрое развитие PDM-систем: появились ENOVIA и Smarteam от Dassault Systemes, Teamcenter от UGS и другие.

Среди российских систем PDM наиболее известными являются Лоцман:PLM компании Аскон, PDM STEP Suite, разработанная под НПО «Прикладная логистика», Party Plus компании Лоция-Софт и т.д.

Итак, термин САПР (система автоматизации проектирования) подразумевает комплексный подход к разработке изделия и включает совокупность систем CAD/CAM/CAE. Развитие систем геометрического моделирования, анализа и расчета характеристик изделия сопровождается интеграцией в рамках предприятия. Мировой рынок обособленных CAD/CAM решений уже насыщен, системы близки по функциональности, и темпы роста этого сегмента рынка минимальны. По этой причине происходит усиление интеграции систем CAD/CAM/CAE с системами PDM, которые позволяют хранить и управлять проектно-конструкторской документацией на разрабатываемые изделия, вносить в документацию изменения, поддерживать хранение истории этих изменений. Распространение функций PDM-систем на все этапы жизненного цикла продукции превращает их в системы PLM (Product Lifecycle Management). Развитие систем PLM обеспечивает максимальную интеграцию процессов проектирования, производства, модернизации и сопровождения продукции предприятия и по сути имеет много общего с концепцией интегрированной поддержки жизненного цикла изделия.

2. Опишите устройства ввода-вывода информации ЭВМ

К основным устройствам ввода информации в персональный компьютер относятся следующие устройства: клавиатура, мышь, шар (track-ball), сканер, графический планшет (digitizer) и т. д.

Рассмотрим подробнее назначение и принципиальное устройство каждого из них.

Клавиатура.

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

По расположению клавиш настольные клавиатуры делятся на два основных типа, функционально ничуть не уступающие друг другу:

Функциональные клавиши располагаются в двух вертикальных рядах, отдельных групп клавиш управления курсором нет. Всего в такой клавиатуре 84 клавиши. Некоторые считают этот стандарт устаревшим.

Усовершенствованная (расширенная), имеет 101 или 102 клавиши. Клавиатурой такого типа снабжаются сегодня почти все настольные персональные компьютеры. Количество функциональных клавиш в усовершенствованной клавиатуре не 10, а 12. Логично выделены группы клавиш для работы с текстами и управления курсором, продублированы некоторые специальные клавиши, позволяющие более эргономично работать обеими руками.

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

Расположение буквенных клавиш на компьютерных клавиатурах стандартно. Сегодня повсеместно применяется стандарт QWERTY – по первым шести латинским буквенным клавишам верхнего ряда. Ему соответствует отечественный стандарт ЙЦУКЕН расположения клавиш кириллицы, практически аналогичный расположению клавиш на пишущей машинке.

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

Устройство. Клавиатура представляет собой совокупность датчиков, воспринимающих давление на клавиши и замыкающих определенную электрическую цепь, со стандартным разъемом (PS/2, USB) и интерфейсом для подключения к системной плате компьютера. Длительное время выпускались клавиатуры с механическими датчиками. Современные клавиатуры – мембранного типа. Переключатель представляет собой набор мембран: активная – верхняя, пассивная – нижняя, разделяющая.

Внутри корпуса клавиатуры помимо датчиков расположены электронные платы дешифрации сигнала. Обмен данными между клавиатурой и системной платой осуществляется 11-битовыми блоками (8 разрядов плюс служебная информация) по 2-проводному кабелю (сигнал и земля). Клавиатура содержит внутренний контроллер, позволяющий производить самотестирование в момент подключения (одновременная индикация светодиодов «NumLock», «CapsLock», «ScrollLock»), управляющий индикаторами и обеспечивающий связь с системной платой ПК посредством последовательного интерфейса.

Принцип работы. Принцип работы клавиатуры заключается в сканировании переключателей клавиш. Замыканию и размыканию любого из переключателей соответствует уникальный цифровой код (scan code) размером 1 байт. На системной плате прием и обработку сигналов от клавиатуры выполняет специальная микросхема – контроллер клавиатуры.

Внутренний микропроцессор клавиатуры обрабатывает специальный сигнал, поступающий к нему после нажатия любой клавиши и, преобразуя его, последовательно передает центральному процессору сканируемый код. Каждое нажатие клавиши формирует два кода: один по нажатию, другой – по освобождению клавиши.

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

Клавиатура в своей собственной специальной памяти запоминает, какая клавиша была нажата (обычно в памяти клавиатуры может храниться до 20 кодов нажатых клавиш, если процессор не успевает ответить на прерывание). После передачи кода нажатой клавиши процессору эта информация из памяти клавиатуры исчезает.

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

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

Манипуляторы.

Хотя клавиатура еще вовсе не утратила значения для общения пользователя с компьютером, другое устройство ручного ввода информации – мышка – становится все более весомой и важной. Можно с уверенностью утверждать, что на современном компьютере работать без мышки стало почти невозможно: вы тут же увязните в графическом интерфейсе Windows и многих прикладных программ, работающих с окнами, меню, иконками и диалоговыми боксами (если только вы не ас клавиатурных сокращений).

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

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

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

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

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

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

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

Сканер.

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

Сканер – это глаза компьютера. Первоначально они создавались именно для ввода графических образов, рисунков, фотоснимков, чертежей, схем, графиков, диаграмм. Однако, помимо ввода графики, в настоящее время они все шире используются в довольно сложных интеллектуальных системах OCD (Optical Character Recognition), то есть оптического распознания символов. Эти «умные» системы позволяют вводить в компьютер и читать текст.

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

Сканеры бывают различных конструкций.

Программное обеспечение устройств ввода информации.

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

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

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

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

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

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

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

работать с любой бумагой;

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

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

Бесконтактные принтеры используют другую технологию. Наиболее широкое распространение получили следующие виды принтеров: струйные, термические и лазерные.

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

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

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

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

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

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

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

Чтобы напечатать строку символов, принтерная головка движется горизонтально по бумаге и каждая игла ударяет в строго заданной позиции для получения нужного символа. Удар иглы происходит в заданное время, когда она будет занимать точно заданное положение в матрице. Игла выстреливает на ленту – головка принтера никогда не останавливается до тех пор, пока она не достигнет границы бумаги.

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

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

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

В настоящее время большинство принтеров использует для подключения USB-порт, что позволяет осуществлять «горячее» подключение, т. е. без выключения и перезагрузки компьютера, что было немыслимо при использовании LTP-порта.

Однако применение драйверов не ограничивается только описанием возможностей принтера. Ведь чтобы принтер правильно вывел информацию на бумагу, он должен быть грамотен. Для этого ему загружают так называемый «язык управления». В данный момент популярны два языка: PCL и PostScript. Оба языка призваны помочь принтеру правильно и красиво вывести информацию.

Основные характеристики:

тип печати;

интерфейс подключения;

максимальное разрешение;

максимальный формат печати;

тип материала для печати;

плотность материала;

время выхода первой страницы;

скорость печати;

ресурс принтера;

область печати;

подача бумаги;

потребляемая мощность;

уровень шума;

поддержка ОС.

3. Опишите состав лингвистического обеспечения САПР. Подробно остановитесь на диалоговых языках

Лингвистическое обеспечение – совокупность языков, используемых в процессе разработки и эксплуатации САПР.

Под «языком» понимается любое средство общения, любая система символов и знаков для представления и обмена информацией.

Лингвистическое обеспечение образуется следующими языками:

-программирования;

-управления;

-проектирования.

Языки программирования необходимы для создания программного обеспечения при разработке САПР. В принципе языки программирования относят и к программному обеспечению САПР. Здесь мы их подробно рассматривать не будем, информация о них приведена в специальной литературе. Напомним лишь, что к наиболее распространенным языкам программирования относятся Pascal, Fortran, Basic, Си (различных версий). В настоящее время на их базе разработаны и повсеместно используются среды программирования такие, как, соответственно, Delphi, Visual Fortran, Visual Basic, Visual Си (также различных версий).

Языки управления служат для управления ЭВМ, периферийными устройствами. Это операционная система Windows, драйверы принтеров и т.д. Эти языки также относят и к программному обеспечению САПР. Они в требуемом в данном курсе объеме были описаны ранее.

Языки проектирования ориентированы на пользователей – проектировщиков и предназначены для эксплуатации САПР, в том числе и САПР технологических процессов (САПР ТП). На них мы и остановимся более подробно. Эта группа языков делится на:

-входные;

-внутренние;

-выходные.

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

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

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

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

Так или иначе место языков проектирования на различных этапах переработки информации в САПР ТП (один из вариантов) показано на рис. 1.

Языки проектирования, построенные на базе классификации

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

«Общесоюзного классификатора промышленной и сельскохозяйственной продукции (ОКП)»;

«Технологического классификатора деталей машиностроения и приборостроения».

Рис. 1

Процесс кодирования сведений о детали заключается в присвоении ей цифрового кода по ОКП и дополнения его кодами основных технологических признаков.

Языки для диалогового проектирования технологических процессов

Исполнения таких языков разные. Это зависит от их разработки конкретными авторами или группами разработчиков. Кратко рассмотрим такой язык, применяемый для диалогового проектирования технологических процессов в рамках САПР ТП «ТехноПро» (автор – Лихачев Андрей Андреевич, распространяется АО «Топ системы»).

Сразу следует отметить, что данная САПР ТП построена на основе СУБД Microsoft Access и поэтому многие сценарии работы естественным образом повторяют действия по работе с данной средой.

При проектировании технологического процесса в системе «ТехноПро» технолог общается с ЭВМ на языке, максимально приближенном к его предметной области. Он оперирует со знакомыми ему понятиями: деталь, операция, переход, карта, эскиз и т.д. Сведения о детали можно вводить с клавиатуры или считывать с введенного заранее в системе T-FLEX электронного чертежа – см. рис. 2.

Рис. 2

Форма для ввода информации, представленная на рисунке содержит привычные для Access и для Windows кнопки, поля, закладки и др. элементы.

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

Рис. 3. Заполнение содержания операции в САПР ТП «ТехноПро»

Рис. 4. Заполнение содержания перехода в САПР ТП «ТехноПро»

Список используемой литературы

Азбелев П.П., Белоусова И.В., Ежов С.Н., Кревский И.Г., Уксусников Ю.Г. Информационное и лингвистическое обеспечение систем логического моделирования: Учеб.пособие /СПбЭТИ, — С.-Пб.,1992.

Разработка трансляторов с языков САПР. Методические указания к выполнению лабораторных работ /Сост.: Кревский И.Г.; ПГТУ. — Пенза, 1993.

Язык описания моделей микропроцессорных БИС ДИСП-Си. Методические указания к выполнению курсовых проектов по курсам «Лингвистическое обеспечение САПР» и «Математическое моделирование в САПР» /Сост.: Кревский И.Г.; ПГТУ. — Пенза, 1993.

Отделение техники и технологий

РЕФЕРАТ

На тему

«Разработка операционных систем»

Содержание

Введение

1. Разработка интерфейса

2. Руководящие принципы

3. Парадигмы

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

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

Парадигмы данных

4. Интерфейс системных вызовов

5. Реализация.

6. Структура системы

7. Многоуровневые системы

8. Экзоядра

9. Системы клиент-сервер

10. Расширяемые системы

11. Потоки ядра

12. Механизм и политика

13. Ортогональность

14. Время связывания

15. Реализация системы сверху вниз и снизу вверх

16. Полезные методы

17. Скрытие аппаратур

18. Косвенность

19. Повторное использование

20. Рентабельность

21. Метод грубой силы

22. Проверка на ошибки

23. Производительность

24. Кэширование

25. Подсказки

26. Использование локальности

27. Оптимизируйте общий случай

28. Управление проектом

29. Мифический человеко-месяц

30. Роль опыта

31. Тенденции и проектирование ОС

32. ОС с большим адресным пространством

33. Сеть

34. Параллельные и распределенные системы

35. Мультимедиа

Заключение

Введение

В среде разработчиков операционных систем ходит множество изустных преданий о том, что такое хорошо и что такое плохо, однако на удивление малое количество из этих историй записано. Наиболее важной книгой можно назвать классический труд Фреда Брукса, в котором автор делится своим опытом проектирования и реализации операционной системы IBM OS/360. Материал выпущенного к 20-летней годовщине издания был пересмотрен, к тому же в содержание книги было включено несколько новых глав. Вероятно, единственной книгой по операционным системам, в которой серьезно обсуждается тема проектирования.

Тремя классическими трудами по проектированию операционных систем являются как и книги Брукса, эти три статьи успешно пережили время, прошедшее с момента их написания. Большая часть рассматриваемых в них вопросов сохранила свою актуальность и в наши дни.

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

Природа проблемы проектирования

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

Цели.

Чтобы проект операционной системы был успешным, разработчики должны иметь четкое представление о том, чего они хотят. При отсутствии цели очень трудно принимать последующие решения. Чтобы этот вопрос стал понятнее, полезно взглянуть на два языка программирования, PL/I и С++. Язык PL/I был разработан корпорацией IBM в 60-е годы, так как поддерживать одновременно FORTRAN и COBOL и слушать при этом за спиной ворчание ученых о том, что Algol лучше, чем FORTRAN и COBOL вместе взятые, было невыносимо. Поэтому был создан комитет для создания нового языка, удовлетворяющего запросам всех программистов: PL/I. Этот язык обладал некоторыми чертами языка FORTRAN, некоторыми особенностями языка COBOL и некоторыми свойствами языка Algol. Проект потерпел неудачу, потому что ему недоставало единой концепции. Проект представлял собой лишь набор свойств, конфликтующих друг с другом, к тому же язык PL/I был слишком громоздким и неуклюжим, чтобы программы на нем можно было эффективно компилировать.

Теперь взглянем на язык С++. Он был спроектирован всего одним человеком (Деннисом Ритчи) для единственной цели (системного программирования). Успех его был колоссален, и это не в последнюю очередь объяснялось тем, что Ритчи знал, чего хотел и чего не хотел. В результате спустя десятилетия после своего появления этот язык все еще широко распространен. Наличие четкого представления о своих целях является решающим.

Чего же хотят разработчики операционных систем? Очевидно, ответ варьируется от системы к системе и будет разным для встроенных систем и серверных систем

Для универсальных операционных систем основными являются следующие четыре пункта:

1. Определение абстракций.

2. Предоставление примитивных операций.

3. Обеспечение изоляции.

4. Управление аппаратурой.

Ниже будет рассмотрен каждый из этих пунктов.

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

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

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

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

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

Почему так сложно спроектировать операционную систему?

Закон Мура гласит, что аппаратное обеспечение компьютера увеличивает свою производительность в 100 раз каждые десять лет. Никто, к сожалению, так и не сформулировал ничего подобного для программного обеспечения. Никто и не говорит, что операционные системы вообще совершенствуются с годами. В самом деле, можно утверждать, что некоторые из них даже стали хуже в определенных аспектах (таких как надежность), чем, например, операционная система UNIX Version 7 образца 70-х годов.

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

Во-первых, операционные системы стали крайне громоздкими программами. Никто в одиночку не может, засев за персональный компьютер на несколько месяцев, написать операционную систему. Все современные версии UNIX превосходят 1 млн строк исходного текста. Операционная система Windows 2000 состоит из 29 млн строк кода. Ни один человек на Земле не способен понять даже одного миллиона строк, не говоря уже о 29 миллионах. Если вы создаете продукт, который ни один из разработчиков не может даже надеяться понять целиком, не удивительно, что результаты часто оказываются далеки от оптимальных.

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

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

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

В-шестых, у разработчиков операционной системы на самом деле нет четкого представления о том, как будет использоваться их система, поэтому они должны обеспечить достаточную степень универсальности. При проектировании таких систем, как UNIX или Windows 2000, не предполагалось их использование для работы с электронной почтой или запуск web-браузера под их управлением, однако многие современные компьютеры в основном только для этого и используются. Трудно себе представить проектировщика морского судна, который не знал бы, что он проектирует: рыболовецкое судно, пассажирское судно или военный корабль.

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

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

Разработка интерфейса

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

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

Руководящие принципы

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

Принцип 1. Простота.

Простой интерфейс легче понять и реализовать без ошибок. Всем разработчикам систем следует помнить эту знаменитую цитату французского летчика и писателя Антуана де Сент-Экзюпери:

Совершенство достигается не тогда, когда уже больше нечего добавить, а когда больше нечего убавить. Этот принцип утверждает, что лучше меньше, чем больше, по крайней мере, применительно к операционным системам. Другими словами, этот принцип может быть выражен следующей аббревиатурой, предлагающей программисту, в чьих мыслительных способностях возникают сомнения, не усложнять систему: KISS (Keep It Simple, Stupid).

Принцип 2. Полнота.

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

Другими словами, операционная система должна выполнять то, что от нее требуется, но не более того. Если пользователю нужно хранить данные, операционная система должна предоставлять для этого некий механизм. Если пользователям необходимо общаться друг с другом, операционная система должна предоставлять механизм общения и т. д. В своей речи по поводу получения награды Turing Award один из разработчиков систем CTSS и MULTICS Фернандо Корбато объединил понятия простоты и полноты и сказал:

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

Парадигмы

Когда цели установлены, можно начинать проектирование. Можно начать, например, со следующего: подумать, как будет представать система перед пользователями. Один из наиболее важных вопросов заключается в том, чтобы все функции системы хорошо согласовывались друг с другом и обладали тем, что часто называют архитектурной согласованностью. При этом важно различать два типа «пользователей» операционной системы. С одной стороны, существуют пользователи, взаимодействующие с прикладными программами; с другой стороны, есть программисты, пишущие эти прикладные программы. Первые большей частью имеют дело с графическим интерфейсом пользователя, тогда как последние в основном взаимодействуют с интерфейсом системных вызовов. Если задача заключается в том, чтобы иметь единый графический интерфейс пользователя, заполняющий всю систему, как, например, в системе Macintosh, тогда разработку следует начать отсюда. Если же цель состоит в том, чтобы обеспечить поддержку различных возможных графических интерфейсов пользователя, как в системе UNIX, тогда в первую очередь должен быть разработан интерфейс системных вызовов. Начало разработки системы с графического интерфейса пользователя представляет собой, по сути, проектирование сверху вниз. Вопрос заключается в том, какие функции будет этот интерфейс иметь, как будет пользователь с ними взаимодействовать и как следует спроектировать систему для их поддержки. Например, если большинство программ отображает на экране значки, а затем ждет, когда пользователь щелкнет на них мышью, это предполагает использование управляемой событиями модели для графического интерфейса пользователя и, возможно, для операционной системы. С другой стороны, если экран в основном заполнен текстовыми окнами, тогда, вероятно, лучшей представляется модель, в которой процессы считывают символы с клавиатуры.

Реализация в первую очередь интерфейса системных вызовов представляет собой проектирование снизу вверх. Здесь вопросы заключаются в том, какие функции нужны программистам. В действительности для поддержки графического интерфейса пользователя требуется не так уж много специальных функций. Например, оконная система под названием X Windows, используемая в UNIX, представляет собой просто большую программу на языке С, которая обращается к клавиатуре, мыши и экрану с системными вызовами read и write. Оконная система X Windows была разработана значительно позже операционной системы UNIX, но для ее работы не потребовалось большого количества изменений в операционной системе. Это подтверждает тот факт, что система UNIX обладает полнотой в достаточной степени.

Парадигмы интерфейса пользователя.

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

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

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

Парадигмы исполнения.

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

Широкое распространение получили две парадигмы: алгоритмическая и движимая событиями. Алгоритмическая парадигма основана на идее, что программа запускается для выполнения некоторой функции, известной заранее или задаваемой в виде параметров. Эта функция может заключаться в компиляции программы, составлении ведомости или пилотировании самолета до Сан-Франциско. Базовая логика жестко прошита в код программы, при этом программа время от времени обращается к системным вызовам, чтобы получить ввод пользователя, обратиться к системным службам и т. д.

Другая парадигма исполнения представляет собой парадигму управления событиями (листинг 12.1, б). Здесь программа выполняет определенную инициализацию, например, отображает какое-либо окно, а затем ждет, когда операционная система сообщит ей о первом событии. Этим событием может быть нажатие клавиши или перемещение мыши. Такая схема полезна для программ, активно взаимодействующих с пользователем.

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

Парадигмы данных.

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

Первая карта представляла собой инструкцию для оператора. Он должен был достать из шкафа бобину номер 781 и установить ее на накопителе 8. Вторая карта являлась командой операционной системе запустить только что откомпилированную с языка FORTRAN программу, отображая INPUT (означающий устройство чтения перфокарт) на логическую ленту 1, дисковый файл MYDATA на логическую ленту 2, принтер OUTPUT на логическую ленту 3, перфоратор PUNCH на логическую ленту 4 и физический накопитель на магнитной ленте ТАРЕ08 на логическую ленту 5.

Синтаксис языка FORTRAN позволяет читать и писать логические ленты. При чтении с логической ленты 1 программа получает ввод с перфокарт. При помощи записи на логическую ленту 3 программа может вывести результаты на принтер. Обращаясь к логической ленте 5, программа может читать и писать магнитную ленту 781 и т. д. Обратите внимание, что идея магнитной ленты представляла собой всего лишь парадигму (модель) для объединения устройства чтения перфокарт, принтера, перфоратора, дисковых файлов и магнитофонов. В данном примере только логическая лента 5 была физической лентой. Все остальное представляло собой обычные файлы для подкачки данных. Это была примитивная парадигма, но она была шагом в правильном направлении.

Затем появилась операционная система UNIX, которая пошла значительно дальше в этом направлении, используя модель «все суть файлы». При использовании этой парадигмы все устройства ввода-вывода рассматриваются как файлы, которые можно открывать и управлять ими, как обычными файлами. Операторы на языке С открывают настоящий дисковый файл и терминал пользователя. Последующие операторы могут использовать дескрипторы файлов fd1 и fd2, чтобы читать из этих файлов и писать в них. С этого момента нет разницы между доступом к файлу и доступом к терминалу, не считая того, что при обращении к терминалу не разрешается операция перемещения указателя в файле.

Операционная система UNIX не только объединяет файлы и устройства ввода-вывода, но также позволяет получать доступ к другим процессам через каналы, как к файлам. Более того, если поддерживается отображение файлов на адресное пространство памяти, процесс может обращаться к своей виртуальной памяти так, как если бы это был файл. Наконец, в версиях UNIX, поддерживающих файловую систему /рrос, строка на языке С позволяет процессу (попытаться) получить доступ к памяти процесса 501 для чтения и записи при помощи дескриптора файла fd3, что может быть полезно, например, при отладке программы.

Операционная система Windows 2000 идет в использовании этой модели еще дальше, представляя все, что есть в системе, в виде объектов. Получив дескриптор файла, процесса, семафора, почтового ящика или другого объекта ядра, процесс может выполнять с этим объектом различные действия. Эта парадигма является еще более общей, чем используемая в UNIX, и значительно более общей, чем в FORTRAN.

Объединяющие парадигмы также встречаются в других контекстах. Следует отметить один из них: Всемирную паутину (Web). Используемая в Паутине парадигма состоит в том, что все киберпространство заполнено документами, у каждого их которых есть свой адрес URL. Обратившись по соответствующему указателю URL (введя его с клавиатуры или щелкнув мышью по ссылке), вы получаете этот документ. В действительности многие «документы» вовсе не являются документами, но формируются программой или сценарием оболочки, когда поступает запрос. Например, когда пользователь запрашивает в Интернет-магазине список компакт-дисков конкретного исполнителя, документ создается на лету программой. Он совершенно точно не существовал до того, как был получен запрос.

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

Интерфейс системных вызовов

Если исходить из высказанного Корбато принципа минимального механизма, тогда операционная система должна предоставлять настолько мало системных вызовов, насколько это возможно (необходимый минимум), и каждый системный вызов должен быть настолько прост, насколько это возможно (но не проще). Объединяющая парадигма данных может играть главную роль в этом. Например, если файлы, процессы, устройства ввода-вывода и прочее будут выглядеть как файлы или объекты, все они могут читаться при помощи всего одного системного вызова read. В противном случае пришлось бы иметь различные системные вызовы, такие как read_file, read_proc, read_tty и т. д.

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

exec(name. argp. envp);

Данный системный вызов загружает исполняемый файл пате и передает ему аргументы, на которые указывает argp, и список переменных окружения, на который указывает envp.

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

Разумеется, пытаясь использовать один-единственный системный вызов для всех случаев жизни, легко дойти до крайностей. Для создания процесса в операционной системе UNIX требуется два системных вызова: fork, за которым следует exec. У первого вызова нет параметров; у второго вызова три параметра. Для сравнения: у вызова Win32 API для создания процесса, CreateProcess, 10 параметров, один из которых представляет собой указатель на структуру с дополнительными 18 параметрами. Давным-давно следовало задать вопрос: «Произойдет ли катастрофа, если мы опустим что-нибудь из этого?» Правдивый ответ должен был звучать так: «В некоторых случаях программист будет вынужден совершить больше работы для достижения определенного эффекта, зато мы получим более простую, компактную и надежную операционную систему». Конечно, человек, предлагающий версию с этими 10 + 18 параметрами, мог добавить: «Но пользователи любят все эти возможности». Возразить на это можно было бы так: «Еще больше им нравятся системы, которые используют мало памяти и никогда не ломаются». Компромисс, заключающийся в большей функциональности за счет использования большего объема памяти, по крайне мере, виден невооруженным глазом и ему можно дать оценку (так как стоимость памяти известна). Однако трудно оценить количество дополнительных сбоев в год, которые появятся благодаря внедрению новой функции. Кроме того, неизвестно, сделали бы пользователи тот же выбор, если им заранее была известна эта скрытая цена. Этот эффект можно резюмировать первым законом программного обеспечения Таненбаума:

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

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

Простота является не единственным принципом, которым следует руководствоваться при разработке системных вызовов. Следует также помнить о фразе, сказанной Б. Лэмпсоном в 1984 году: Не скрывай мощь.

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

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

С другой стороны, некоторые протоколы удаленного доступа к файлам не требуют соединений. Например, протокол NFS не требует соединений, как было показано в главе 10. Каждый вызов NFS является независимым, поэтому файлы не открываются до их чтения или записи, разумеется, файлы не нужно закрывать после чтения или записи. Всемирная паутина также не требует соединений: чтобы прочитать web-страницу, вы просто запрашиваете ее. Не требуется никаких предварительных настроек (TCP-соединение все-таки требуется, но оно представляет собой более низкий уровень протокола; протокол HTTP, используемый для доступа к самой web-странице, не требует соединений).

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

Другой вопрос, возникающий при проектировании интерфейса системных вызовов, заключается в его открытости. Список системных вызовов, определяемых стандартом POSIX, легко найти. Эти системные вызовы поддерживаются всеми системами UNIX, как и небольшое количество других вызовов, но полный список всегда публикуется. Корпорация Microsoft, напротив, никогда не публиковала список системных вызовов Windows 2000. Вместо этого публикуются функции интерфейса Win32 API, а также вызовы других интерфейсов; эти списки содержат огромное количество библиотечных вызовов (более 13 000 в Windows 2000), но только малое их число является настоящими системными вызовами. Аргумент в пользу открытости системных вызовов заключается в том, что программистам становится известна цена использования функций. Функции, исполняемые в пространстве пользователя, выполняются быстрее, чем те, которые требуют переключения в режим ядра. Закрытость системных вызовов также имеет свои преимущества, заключающиеся в том, что в результате достигается гибкость в реализации библиотечных процедур. То есть разработчики операционной системы получают возможность изменять действительные системные вызовы, сохраняя при этом работоспособность прикладных программ.

Реализация

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

Структура системы

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

Многоуровневые системы

Разумный подход, установившийся с годами, заключается в создании многоуровневых систем. Система THE, разработанная Э. Дейкстрой, была первой многоуровневой системой. У операционных систем UNIX (см. рис. 10.2) и Windows 2000 также есть многоуровневая структура, но уровни в них в большей степени представляют собой способ описания системы, чем фактический руководящий принцип, использованный при ее построении.

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

На уровне 4 мы обнаружим драйверы устройств, каждый из которых работает как отдельный поток, со своим состоянием, счетчиком команд, регистрами и т. д., возможно (но не обязательно), в адресном пространстве ядра. Такое устройство может существенно упростить структуру ввода-вывода, потому что когда возникает прерывание, оно может быть преобразовано в системный вызов unlock на мьютексе и обращение к планировщику, чтобы (потенциально) запустить новый готовый поток, который был блокирован мьютексом. Этот подход используется в системе MINIX, но в операционных системах UNIX, Linux и Windows 2000 обработчики прерываний реализованы как независимая часть системы, а не потоки, которые сами могут управляться планировщиком, приостанавливаться и т. д. Поскольку основная сложность любой операционной системы заключается во вводе-выводе, заслуживает внимания любой способ сделать его более удобным для обработки и более инкапсулированным.

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

Экзоядра

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

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

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

Сквозной аргумент может быть расширен почти до пределов всей операционной системы. Он утверждает, что операционная система не должна делать того, что пользовательская программа может сделать сама. Например, зачем нужна файловая система? Почему бы не позволить пользователю просто читать и писать участки диска защищенным способом? Конечно, большинству пользователей нравится работать с файлами, но, согласно сквозному аргументу, файловая система должна быть библиотечной процедурой, которую можно скомпоновать с любой программой, нуждающейся в файлах. Этот подход позволяет различным программам использовать различные файловые системы. Такая цепь рассуждений приводит к выводу, что операционная система должна только обеспечивать безопасное распределение ресурсов (например, процессорного времени или дисков) среди соревнующихся за них пользователей. Экзоядро представляет собой операционную систему, построенную в соответствии со сквозным аргументом [111].

Системы клиент-сервер

Компромиссом между операционной системой, которая делает все, и операционной системой, не делающей ничего, является операционная система, делающая кое-что. Результатом такого дизайна является схема микроядра, при которой большая часть операционной системы представляет собой серверные процессы, работающие на уровне пользователя (см. рис. 1.23). Такое устройство обладает наибольшей модульностью и гибкостью по сравнению с другими схемами. Предел гибкости заключается в том, чтобы каждый драйвер устройства также работал в виде пользовательского процесса, полностью защищенного от ядра и других драйверов. Удаление драйверов из ядра позволяет устранить наибольший источник нестабильности в любой операционной системе – полные ошибок драйверы, написанные третьими фирмами.

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

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

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

Главная проблема такого подхода, и проблема микроядер вообще, заключается в снижении производительности, вызываемом дополнительными переключениями контекста. Однако практически вся работа по созданию микроядер была выполнена много лет назад, когда центральные процессоры были значительно медленнее. Сегодня не так уж много приложений, использующих каждую каплю мощности процессора, которые не могут смириться с малейшей потерей производительности. В конце концов, когда работает текстовый редактор или web-браузер, центральный процессор простаивает около 90 % времени. Если операционная система, основанная на микроядре, превращает систему с процессором, работающем на частоте 900 МГц, в надежную систему, аналогичную по производительности системе с частотой 800 МГц, мало кто из пользователей станет жаловаться. Большинство пользователей были просто счастливы всего несколько лет назад, когда приобрели свой предыдущий компьютер с потрясающей тогда частотой процессора в 100 МГц.

Расширяемые системы

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

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

Потоки ядра

Еще один вопрос, имеющий отношение к данной теме, независимо от выбора структурной модели – это системные потоки. Иногда бывает удобно позволить существовать потокам ядра отдельно от пользовательских процессов. Эти потоки могут работать в фоновом режиме, записывая «грязные» страницы на диск, занимаясь свопингом процессов и т. д. На самом деле ядро само может целиком состоять из таких потоков. Когда пользователь обращается к системному вызову, пользовательский поток не выполняется в режиме ядра, а блокируется и передает управление потоку ядра, который принимает управление для выполнения работы.

Помимо потоков ядра, работающих в фоновом режиме, большинство систем также запускают в фоновом режиме множество процессов-демонов. Хотя они и не являются частью операционной системы, они часто выполняют «системные» функции. Это может быть получение и отправка электронной почты, а также обслуживание различных запросов удаленных пользователей, как, например, FTP или web-страницы.

Механизм и политика

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

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

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

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

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

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

Ортогональность

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

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

Понятие ортогональности также встречается в операционных системах в различных формах. Одним из примеров является системный вызов clone операционной системы Linux, создающий новый поток. В качестве параметра этот вызов принимает битовый массив, задающий такие режимы, как независимое друг от друга совместное использование или копирование адресного пространства, рабочего каталога, дескрипторов файлов и сигналов. Если копируется все, то мы получаем новый процесс, как и при использовании системного вызова fork. Если ничего не копируется, это означает, что создается новый поток в текущем процессе. Однако вероятно и создание промежуточных форм, невозможных в традиционных системах UNIX. Разделение свойств и их ортогональность позволяет получить более детальную степень управления.

Другое применение ортогональности – разделение понятий процесса и потока в Windows 2000. Процесс представляет собой контейнер для ресурсов, не более и не менее. Поток представляет собой объект планирования. Когда один процесс получает дескриптор от другого процесса, не имеет значения, сколько потоков у него есть. Когда планировщик выбирает поток, не важно, какому процессу он принадлежит. Эти понятия ортогональны.

Наш последний пример ортогональности возьмем из операционной системы UNIX. Создание процесса происходит здесь в два этапа: при помощи системных вызовов fork и exec. Создание нового адресного пространства и заполнение его новым образом памяти в данном случае разделены, что позволяет выполнить определенные действия между этими этапами. В операционной системе Windows 2000 эти два этапа нельзя разделить, то есть концепции создания нового адресного пространства и его заполнения новым образом памяти не являются ортогональными в этой системе. Последовательность системных вызовов clone и exec в системе Linux является еще более ортогональной, так как в данном случае возможно еще более детальное управление этими действиями. Общее правило может быть сформулировано следующим образом: наличие небольшого количества ортогональных элементов, которые могут комбинироваться различными способами, позволяет создать небольшую простую и элегантную систему.

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

Имена, создаваемые для использования их людьми, представляют собой символьные строки формата ASCII или Unicode и, как правило, являются иерархическими. Так, иерархия отчетливо видна на примере путей файлов, например, путь /usr/ast/books/mos2/chap-12 состоит из имен каталогов, поиск которых следует начинать в корневом каталоге. Адреса URL также являются иерархическими. Например, URL www.cs.vu.nl/~ast/ указывает на определенную машину (www) определенного факультета (cs) определенного университета (vu) определенной страны (nl). Участок URL после косой черты обозначает определенный файл на указанной машине, в данном случае по умолчанию это файл www/index.html в домашнем каталоге пользователя ast. Обратите внимание, что URL (а также адреса DNS вообще, включая адреса электронной почты) пишутся «задом наперед», начинаясь с нижнего уровня дерева, в отличие от имен файлов, начинающихся с вершины дерева. На это можно взглянуть и по-другому, если положить дерево горизонтально. При этом в одном случае дерево будет начинаться слева и расти направо, а в другом случае, наоборот, будет начинаться справа и расти влево.

Часто используется двухуровневое именование: внешнее и внутреннее. Например, к файлам всегда можно обратиться по имени, представляющему собой символьную строку. Кроме этого, почти всегда существует внутреннее имя, используемое системой. В операционной системе UNIX реальным именем файла является номер его i-узла. Имя в формате ASCII вообще не используется внутри системы. В действительности это имя даже не является уникальным, так как на файл может указывать несколько ссылок. А в операционной системе Windows 2000 в качестве внутреннего имени используется индекс файла в таблице MFT. Работа каталога заключается в преобразовании внешних имен во внутренние.

Во многих случаях (таких как приведенный выше пример с именем файла) внутреннее имя файла представляет собой уникальное целое число, служащее индексом в таблице ядра. Другие примеры имен-индексов: дескрипторы файлов в системе UNIX и дескрипторы объектов в Windows 2000. Обратите внимание, что ни у одного из данных примеров имен нет внешнего представления. Они предназначены исключительно для внутреннего использования системой и работающими процессами. В целом использование для временных имен табличных индексов, не сохраняющихся после перезагрузки системы, является удачным замыслом.

Время связывания

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

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

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

Языками программирования часто поддерживаются различные виды связывания для переменных. Глобальные переменные связывает с конкретным виртуальным адресом компилятор. Это пример раннего связывания. Локальным переменным процедуры виртуальные адреса назначаются (в стеке) во время выполнения процедуры. Это пример промежуточного связывания. Переменным, хранящимся в куче (память для которых выделяется при помощи процедуры malloc в программах на языке С или процедуры new в программах на языке Java), виртуальный адрес назначается только на время их фактического использования. Это пример позднего связывания.

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

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

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

Альтернативная стратегия заключается в создании таблицы процессов в виде связного списка мини-таблиц, начиная с одной-единственной мини-таблицы. Когда эта таблица заполняется, в глобальном пуле выделяется память под следующую таблицу, которая связывается с первой таблицей. Таким образом, таблица процесса не переполнится, пока не закончится вся память у ядра.

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

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

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

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

Реализация системы сверху вниз и снизу вверх

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

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

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

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

Полезные методы.

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

Скрытие аппаратуры

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

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

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

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

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

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

Однако другие различия, такие как различия в центральных процессорах, не могут быть скрыты при помощи единого двоичного кода, определяющего при загрузке тип процессора. Один из способов решения данной проблемы состоит в использовании условной трансляции единого исходного кода. В исходных файлах для различных конфигураций используются определенные флаги компиляции, позволяющие получать из единого исходного текста различные двоичные файлы в зависимости от центрального процессора, длины слова, блока MMU и т. д. Представьте себе операционную систему, которая должна работать на компьютерах с процессорами Pentium и UltraSPARC, требующих различных программ инициализации. В зависимости от значения константы CPU, определяемой в заголовочном файле config.h, будет выполняться либо один тип инициализации, либо другой. Поскольку в двоичном файле содержится только один вариант программы, потери эффективности не происходит.

В качестве второго примера предположим, что нам требуется тип данных Register, который должен состоять из 32 бит на компьютере с процессором Pentium и 64 бит на компьютере с процессором UltraSPARC. Этого можно добиться при помощи условного кода в листинге 12.3,6 (при условии, что компилятор воспринимает тип int, как 32-разрядное целое, а тип long – как 64-разрядное). Как только это определение дано (возможно, в заголовочном файле, включаемом во все остальные исходные файлы), программист может просто объявить переменные типа Register и быть уверенным, что эти переменные имеют правильный размер.

Разумеется, заголовочный файл config.h должен быть определен корректно. Для процессора Pentium он может выглядеть примерно так:

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

Некоторые читатели могут удивиться, почему переменные CPU и WORD_LENGTH управляются различными макросами. В определении константы Register можно сделать ветвление программы, устанавливая ее значение в зависимости от значения константы CPU, то есть устанавливая значение константы Register равной 32 бит для процессора Pentium и 64 бит для процессора UltraSPARC. Однако эта идея не слишком удачна. Что произойдет, если позднее мы соберемся переносить систему на 64-разрядный процессор Intel Itanium? Для этого нам пришлось бы добавить третий условный оператор, для процессора Itanium. При том, как это было сделано, нужно только добавить строку в файл config.h для процессора Itanium.

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

Косвенность

Иногда говорят, что нет такой проблемы в кибернетике, которую нельзя решить на другом уровне косвенности. Хотя это определенное преувеличение, во фразе имеется и доля истины. Рассмотрим несколько примеров. В системах на основе процессора Pentium при нажатии клавиши аппаратура формирует прерывание и помещает в регистр устройства не символ ASCII, а скан-код клавиши. Более того, когда позднее клавиша отпускается, генерируется второе прерывание, также с номером клавиши. Такая косвенность предоставляет операционной системе возможность использовать номер клавиши в качестве индекса в таблице, чтобы получить по его значению символ ASCII. Этот способ облегчает обработку разных клавиатур, существующих в различных странах. Наличие информации как о нажатии, так и об отпускании клавиш позволяет использовать любую клавишу в качестве регистра, так как операционной системе известно, в котором порядке нажимались и отпускались клавиши.

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

Еще одним примером косвенности служит использование старших номеров устройств в UNIX. В ядре содержатся две таблицы, одна для блочных устройств и одна для символьных, индексированные старшим номером устройства. Когда процесс открывает специальный файл, например /dev/hd0, система извлекает из i-узла информацию о типе устройства (блочное или символьное), а также старший и младший номера устройств и, используя их в качестве индексов, находит в таблице драйверов соответствующий драйвер. Такой вид косвенности облегчает реконфигурацию системы, так как программы имеют дело с символьными именами устройств, а не с фактическими именами драйверов.

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

В определенном смысле использование макросов, как, например, также представляет собой одну из форм косвенности, так как программист может написать программу, не зная фактической величины таблицы. Считается хорошей практикой давать символьные имена всем константам (иногда кроме –1, 0 и 1) и помещать их в заголовки с соответствующими комментариями.

Повторное использование

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

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

Реентерабельность

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

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

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

Метод грубой силы

Применение простых решений под названием метода грубой силы с годами приобрело негативный оттенок, однако простота решения часто оказывается преимуществом. В каждой операционной системе есть множество процедур, которые редко вызываются или которые оперируют таким небольшим количеством данных, что оптимизировать их нет смысла. Например, в системе часто приходится искать какой-либо элемент в таблице или массиве. Метод грубой силы в данном случае заключается в том, чтобы оставить таблицу в том виде, в каком она есть, никак не упорядочивая элементы, и производить поиск в ней линейно от начала к концу. Если число элементов в таблице невелико (например, не более 100), выигрыш от сортировки таблицы или применения кэширования будет невелик, но программа станет гораздо сложнее и, следовательно, вероятность содержания в ней ошибок резко возрастет. Разумеется, для функций, находящихся в критических участках системы, например в процедуре, занимающейся переключением контекста, следует предпринять все меры для их ускорения, возможно даже писать их (Боже упаси!) на ассемблере. Но большая часть системы не находится в критическом участке. Так, ко многим системным вызовам редко обращаются. Если системный вызов fork выполняется раз в 10 с, а его выполнение занимает 10 мс, тогда, даже если удастся невозможное – оптимизация, после которой выполнение системного вызова fork будет занимать 0 мс, – общий выигрыш составит всего 0,1 %. Если после оптимизации код станет больше и будет содержать больше ошибок, то в данном случае лучше оптимизацией не заниматься.

Проверка на ошибки прежде всего

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

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

Если системному вызову удается пробраться сквозь все тесты, тогда становится ясно, что он завершится успешно. В этот момент ему можно выделять ресурсы.

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

Многие системы страдают подобными «заболеваниями» в форме утечки памяти. Довольно часто программы обращаются к процедуре malloc, чтобы получить память, но забывают позднее обратиться к функции free, чтобы освободить ее. Вся память системы постепенно исчезает, пока система не зависает.

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

Производительность

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

Кэширование

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

Мы уже наблюдали использование кэша в файловой системе, где он хранит некоторое количество недавно использовавшихся блоков диска, что позволяет избежать обращения к диску при чтении блока. Однако кэширование может также применяться и для других целей. Например, обработка путей к файлам отнимает удивительно много процессорного времени. Рассмотрим снова пример из системы UNIX.Чтобы найти файл /usr/ast/mbox, потребуется выполнить следующие обращения к диску:

1. Прочитать i-узел корневого каталога (i-узел 1).

2. Прочитать корневой каталог (блок 1).

3. Прочитать i-узел каталога /usr (i-узел 6).

4. Прочитать каталог /usr (блок 132).

5. Прочитать i-узел каталога /usr/ast (i-узел 26).

6. Прочитать каталог /usr/ast (блок 406).

Чтобы просто определить номер i-узла искомого файла, нужно как минимум шесть раз обратиться к диску. Если размер файла меньше размера блока (например, 1024 байт), то, чтобы прочитать содержимое файла, нужно восемь обращений к диску.

В некоторых операционных системах обработка путей файлов оптимизируется при помощи кэширования пар (путь, i-узел).

Когда файловая система должна найти файл по пути, обработчик путей сначала обращается к кэшу и ищет в нем самую длинную подстроку, соответствующую обрабатываемому пути. Если обрабатывается путь /usr/ast/grants/stw, кэш отвечает, что номер i-узла каталога /usr/ast равен 26, так что поиск может быть начат с этого места и количество обращений к диску может быть уменьшено на четыре. Недостаток кэширования путей состоит в том, что соответствие имени файла номеру его i-узла не является постоянным. Представьте, что файл /usr/ast/mbox удаляется и его i-узел используется для другого файла, владельцем которого может быть другой пользователь. Затем файл /usr/ast/mbox создается снова, но на этот раз он получает i-узел с номером 106. Если не предпринять специальных мер, запись кэша будет указывать на неверный номер i-узла. Поэтому при удалении файла или каталога следует удалять из кэша запись, соответствующую этому файлу, а если удаляется каталог, то следует удалить также все записи для содержавшихся в этом каталоге файлов и подкаталогов*.

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

Подсказки

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

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

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

Использование локальности

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

Принцип локальности также применим для файлов. Когда процесс выбирает конкретный рабочий каталог, многие из его последующих файловых обращений, скорее всего, будут относиться к файлам, расположенным в этом каталоге Производительность можно повысить, если поместить все файлы каталога и их i-узлы близко друг к другу на диске. Именно этот принцип лежит в основе файловой системы Berkeley Fast File System .

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

Оптимизируйте общий случай

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

В качестве первого примера рассмотрим вхождение в критическую область. В большинстве случаев процессу будет удаваться вход в критическую область, особенно если внутри этой области процессы не проводят много времени. Операционная система Windows 2000 использует это преимущество, предоставляя вызов Win32 API EnterCriticalSection, который является атомарной функцией, проверяющей флаг в режиме пользователя (с помощью команды процессора TSL или ее эквивалента). Если тест проходит успешно, процесс просто входит в критическую область, для чего не требуется обращения к ядру. Если же результат проверки отрицательный, библиотечная процедура выполняет на семафоре операцию down, чтобы заблокировать процесс. Таким образом, в нормальном случае обращение к ядру не требуется.

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

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

Управление проектом

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

Мифический человеко-месяц

В своей классической книге Фред Брукс, один из разработчиков системы OS/360, занявшийся впоследствии научной деятельностью, рассматривает вопрос, почему так трудно построить большую операционную систему [44, 46]. Когда большинство программистов встречаются с его утверждением, что специалисты, работающие над большими проектами, могут за год произвести всего лишь 1000 строк отлаженного кода, они удивляются, не прилетел ли профессор Брукс из космоса, с планеты Баг. В конце концов, большинство из них помнит, как они создавали программу из 1000 строк всего за одну ночь. Как же этот объем исходного текста может составлять годовую норму для любого программиста, чей IQ превышает 50?

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

1/3 планирование;

1/6 кодирование;

1/4 тестирование модулей;

1/4 тестирование системы.

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

Заголовком книги Брукс обращает внимание читателя на собственное утверждение о том, что люди и время не взаимозаменяемы. Такой единицы, как человеко-месяц, в программировании не существует. Если в проекте участвуют 15 человек, и на всю работу у них уходит 2 года, то отсюда не следует, что 360 человек справятся с этой работой за один месяц, и вряд ли 60 человек выполнят эту работу за 6 месяцев.

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

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

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

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

Недостаток введения в проект новых людей состоит в том, что их необходимо обучать, модули нужно делить заново, чтобы их число соответствовало числу программистов, требуется провести множество собраний, чтобы скоординировать работу отдельных групп и программистов и т.д. Абдель-Хамид и Мэдник [1] получили экспериментальное подтверждение этого закона. Слегка фривольный вариант закона Брукса звучит так: Если собрать девять рожениц в одной комнате, то они не родят через один месяц.

Роль опыта

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

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

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

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

Тенденции в проектировании операционных систем

Предсказывать всегда трудно, особенно будущее. Например, в 1899 году Чарльз Дьюэл, возглавлявший тогда Бюро патентов США, предложил тогдашнему президенту США Мак-Кинли ликвидировать патентное бюро (а также и рабочее место Чарльза Дьюэла!), поскольку, как он писал, «все, что можно было изобрести, уже изобретено». Тем не менее прошло всего несколько лет, и на пороге патентного бюро показался Томас Эдисон с заявками на электрические лампы, фонограф и кинопроектор. Сменим батарейки в нашем кристальном шаре и попытаемся угадать, что станет с операционными системами в ближайшем будущем.

Операционные системы с большим адресным пространством

По мере того как на смену 32-разрядным машинам приходят 64-разрядные, становится возможным главное изменение в строении операционных систем. 32-разрядное адресное пространство на самом деле не так уж велико. Если попытаться разделить 232 байт на всех жителей Земли, то каждому достанется менее одного байта. В то же время 264 примерно равно 2Ч1019. При этом каждому жителю планеты в 64-разрядном адресном пространстве можно выделить фрагмент размером в 3 Гбайт.

Что можно сделать с адресным пространством в 2Ч1019 байт? Для начала мы можем отказаться от концепции файловой системы. Вместо этого все файлы можно постоянно хранить в памяти (виртуальной). В конце концов, в ней достаточно места для более чем миллиарда полнометражных фильмов, сжатых до 4 Гбайт. Другая возможность заключается в использовании перманентных объектов. Объекты могут создаваться в адресном пространстве и храниться в нем до тех пор, пока не будут удалены все ссылки на объект, после чего сам объект автоматически удаляется. Такие объекты будут сохраняться в адресном пространстве даже после выключения и перезагрузки компьютера. Чтобы заполнить все 64-разрядное адресное пространство, нужно создавать объекты со скоростью 100 Мбайт/с в течение 5000 лет. Разумеется, для хранения такого количества данных потребуется очень много дисков, но впервые в истории ограничивающим фактором стали физические возможности дисков, а не адресное пространство.

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

Еще один системный аспект, который придется пересмотреть при введении 64-разрядных адресов, это виртуальная память. При 264 байт виртуального адресного пространства и 8-килобайтных страницах у нас будет 251 страниц. Работать с обычными таблицами страниц такого размера будет непросто, поэтому потребуется другое решение. Возможно использование инвертированных таблиц страниц, однако также предлагались и другие идеи [321]. В любом случае появление 64-разрядных операционных систем создает новую большую область исследований.

Сеть

Современные операционные системы разрабатывались для автономных компьютеров. Сети были разработаны позднее, и доступ к ним главным образом предоставляется при помощи специальных программ и протоколов, таких как web-браузеры, FTP или telnet. В будущем, возможно, сети будут составлять основу всех операционных систем. Автономный компьютер, не подключенный к сети, будет столь же редким явлением, как и телефон, не подключенный к линии. И, скорее всего, соединения с пропускной способностью в десятки и сотни мегабит в секунду станут нормой.

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

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

Параллельные и распределенные системы

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

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

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

Мультимедиа

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

Что следует оптимизировать?

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

Вот правдивая история о том, как оптимизация принесла больше вреда, чем пользы. Один из студентов автора (имени студента мы здесь называть не будем) написал программу mkfs для системы MINIX. Эта программа создает пустую файловую систему на только что отформатированном диске. На оптимизацию этой программы студент затратил около 6 месяцев. Когда он попытался запустить эту программу, оказалось, что она не работает, после чего потребовалось еще 6 дополнительных месяцев на ее отладку. На жестком диске эту программу, как правило, запускают всего лишь один раз, при установке системы. Она также только раз запускается для каждого гибкого диска – после его форматирования. Каждый запуск программы занимает около 2 с. Даже если бы работа неоптимизированной версии занимала 1 мин, то затрата такого большого времени на оптимизацию столь редко используемой программы являлась бы непроизводительным расходованием ресурсов.

Лозунг, применимый к оптимизации производительности, мог бы звучать так: лучшее – враг хорошего

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

Литература:

www.5-ka.ru

Wikipedia.

Кузнецов Ю.В. «Теория операционных систем».

www.students.ru