В последнее время большое распространение получил так называемый проектный метод, суть которого состоит в выполнении учащимися законченного достаточно объемного проекта. Работа над ним носит самостоятельный и, как правило, коллективный характер. Наиболее распространены проекты гуманитарного содержания, в результате которых создаются газеты, презентации или Web-сайты (см., например, [1,2]). Очень интересен опыт применения проектов в изучении языков программирования, описанный в статье [3], но там проекты, судя по описанию, выполнялись индивидуально.

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

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

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

Постановка задачи. В статье рассматривается проект достаточно сложной программы, имитирующей операционную систему с командной строкой. Для удобства обсуждения стоит дать ему некоторое краткое имя, например, EPOSS (Project of Operating System Simulator; первая буква скромно подставлена от фамилии автора работы).

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

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

Примечания.

1. Регистр символов везде игнорируется (точнее сказать, все буквы преобразуются в заглавные).
2. Команда и имена файлов отделяются друг от друга строго одним пробелом.
3. F1 и F2 – имена виртуальных файлов. В соответствии с логикой команд F1 обязательно должен существовать, а новое имя F2, напротив, не должно совпадать с уже существующим (исключение составляет команда CREATE, где F1 не должно повторять уже имеющееся в каталоге имя).
4. Команда UNERASE корректно восстановит файл лишь в случае, когда после его удаления не было записи на виртуальный диск.

Как видно из таблицы, наша разрабатываемая программа помимо общепринятых команд (таких как DIR или TYPE), будет выполнять и некоторые специфические (например, CREATE). Последние потребуются при отладке и изучении работы с имитатором. Особо хочется сказать о команде UNERASE, добавленной в систему команд исключительно для иллюстрации принципов удаления файлов и во многом в знак признательности к старой доброй программе Питера Нортона Quick Unerase для MS-DOS.

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

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

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

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

В заключение обратим внимание читателей на особенность команд SAVE и LOAD, которые сохраняют на винчестер и потом считывают состояние нашего виртуального диска. В них необходимо писать имя реального файла, следовательно, оно должно удовлетворять принятым в MS-DOS правилам. Рекомендуется для таких файлов задавать расширение TXT, хотя, разумеется, это не обязательно.

Описанный имитатор более всего напоминает операционную систему CP/M [4, 5], но не является ее точной копией.

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

Доступ к виртуальному диску в EPOSS, как и в случае реальной ОС, осуществляется с нескольких уровней (см. рис.1).

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

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

Подчеркнем, что кластеры используются только при работе с содержимым файлов; обращение к информации в каталоге производится напрямую через сектора. Описанный способ доступа к файлам через посредство кластеров является неотъемлемой чертой MS-DOS [6] и до сих пор поддерживается в Windows. Желающие подробнее познакомиться с кластерами и узнать их размер на своем жестком диске, могут обратиться к любопытному эксперименту 7.10.2, описанному в книге [7].

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

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

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

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

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

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

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

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

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

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

Для разработки алгоритма нашего имитатора обратимся к общепринятому представлению в виде блок-схем. На рис.3 они приведены для некоторых процедур, причем рис.3 a и b соответствуют наиболее глобальному уровню алгоритма EPOSS, а рис.3 c и d иллюстрируют структуру для двух типичных команд DIR и COPY. Рассмотрим логику работы имитатора более подробно.

Обратимся к рисунку 3 a, на котором изображен основной цикл работы проекта. Он не содержит ничего неожиданного: имитатор выводит приглашение к диалогу (например, "EPOSS>"), принимает командную строку, а затем расшифровывает ее и (в случае отсутствия ошибок) выполняет. Сигналом для окончания работы данного цикла является ввод пустой строки.

Центральной процедурой рабочего цикла имитатора является выполнение отдельной команды ОС; указанная процедура названа doCommand. Цифровая метка в правом нижнем углу соответствующего прямоугольника обозначает принадлежность данной процедуры к четвертому уровню доступа к информации (деление на уровни обсуждалось выше). Рассмотрим, как устроена процедура doCommand – она представлена на рис.3 b.

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

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

Итак, в результате построения основного алгоритма, мы пришли к необходимости написать несколько (по числу команд) абсолютно независимых друг от друга процедур. Рассмотрим две наиболее типичные из них: cmd_dir, которая выводит список файлов диска, и cmd_copy, обеспечивающую копирование. Они изображены на рис.3 c и d соответственно.

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

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

Как и на предыдущих рисунках, наличие цифры в правой части графических блоков схемы означает ссылку на процедуры или функции определенного программного уровня. В частности, именно этим обстоятельством объясняется отсутствие вывода диагностики ошибок на рис.3 d: эти действия «делегированы» процедуре проверки существования файла, которая, кстати сказать, относится к рассматриваемому нами сейчас уровню 4.

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

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

Итоговые сведения обо всех программных модулях проекта сведены в таблицу 2.

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

Дополнительную информацию о каждой процедуре можно также представить в виде таблиц. Их примерами могут служить таблицы 3 и 4, где представлены данные о функции getCluster и процедуре cmd_era.

Данные о других процедурах и функциях для экономии места не приводятся, но их можно найти на уже упоминавшемся сайте проекта [8].

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

Программная реализация проекта. Полная программа на Паскале, которая решает поставленную задачу, достаточно велика и потому здесь не приводится. Тем не менее, преподаватели легко смогут получить ее авторский вариант с указанного сайта [8].

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

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

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

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

Завершая разговор о работе с системой, покажем, как выглядит небольшой демонстрационный диалог с авторским вариантом проекта EPOSS. На рис.4 изображен вид экрана работающего приложения. Сначала запрашивается версия системы (для этого предусмотрена специальная команда – см. таблицу 1), затем из файла с именем commands распечатывается полный список команд EPOSS. После этого путем набора с клавиатуры создается новый файл, и мы убеждаемся, что он появился в каталоге³ и сохранил введенный текст.

В качестве примера приведем еще один диалог с системой – тестирование одной из наиболее «длинных» команд REN (для простоты воспроизведем не вид экрана, а исключительно текст диалога).

EPOSS>dir
COMMANDS
PROBA
ALF

EPOSS>type alf
ABCDEFGHIJKLMNOPQRSTUVWXYZ

EPOSS>ren al alph
Файл "AL      " не найден

EPOSS>ren alf proba
Файл "PROBA   " уже существует

EPOSS>ren alf alph

EPOSS>dir
COMMANDS
PROBA
ALPH

EPOSS>type alph
ABCDEFGHIJKLMNOPQRSTUVWXYZ

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

Аналогичные проверки должны быть проделаны для каждой из команд имитатора.

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

• Изменить перечень команд ОС, исключив ненужные или добавив желаемые; например, убрать XDIR или UNERASE; добавить для особо продвинутого участника проекта реализацию сложной команды типа дефрагментации.
• Полностью убрать из проекта level2 (см. рис.1), реализующий доступ на уровне кластеров. В принципе для сильного упрощения проекта можно исключить и level 1 (доступ к секторам), оставив в качестве минимального объекта отдельный файл, но, по мнению автора, это нецелесообразно.
• Реализовать набор текста команд ОС с помощью функциональных клавиш. Например, при нажатии <F1> будет вводиться DIR, <F2> – TYPE и т.д. Будучи для программиста очень несложным, подобное усовершенствование заметно облегчает и ускоряет набор, попутно уменьшая количество синтаксических ошибок.
• Организовать возможность вызова и редактирования предыдущих команд: запоминать набранные ранее команды и выводить их по очереди в командную строку, например, по клавишам со стрелкам вверх и вниз.
• Ввести возможность исполнения списка команд ОС из текстового файла (аналог .BAT-файлов в MS-DOS).
• Ввести статус файлов, например, только для чтения и чтение/запись. Скорректировать команды, которые приводят к удалению файлов, с учетом их статуса.
• Сделать запись файлов без фрагментации, т.е. только в последовательно расположенные сектора. При этом существенно упростится работа с каталогом (вместо карты кластеров там будет храниться только ссылка на начало файла и его длина), но зато возникнут трудности с удаленными файлами: на диске будут возникать пустые участки⁴.
• Изменить стратегию поиска свободных кластеров при записи. Эксперименты с дискетами в среде Windows показывают, что существует иная, по сравнению с примененной в авторском варианте проекта, логика заполнения диска: запоминается номер самого последнего заполненного сектора и очередной файл пишется после него, игнорируя возникшие в результате стирания файлов свободные места. Только когда диск заполняется, начинается использования незанятых кластеров, появившихся из-за удаления файлов. По-видимому, такая стратегия имеет определенное практическое преимущество, поскольку на незаполненных дисках обеспечивает отсутствие фрагментации файлов и организует более равномерную нагрузку на сектора дискеты.
• Добавить обработку метасимвола «*», который в операционных системах позволяет формировать шаблоны имен файлов, создавая тем самым возможность одной командой выполнить действие над несколькими файлами с похожими именами.
• Сделать несколько виртуальных дисков. Добавить в имитатор обслуживание новых устройств, например, принтера.
• Реализовать объектную версию программы. Операционная система, манипулирующая с файлами, секторами и другими объектами, хорошо подходит для применения ООП технологии.
• Реализовать проект в виде консольного приложения в среде программирования Delphi. В качестве альтернативы можно предложить продумать оконную реализацию проекта.

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