CC BY
125
УДК 004.623
Д. Николаев, Н. Староверова, А. Хасанова
ПРИНЦИП УРОВНЕЙ АБСТРАКЦИИ И ЕГО ИСПОЛЬЗОВАНИЕ ПРИ РАЗРАБОТКЕ ОПЕРАЦИОННЫХ СИСТЕМ
Ключевые слова: уровни абстракций, операционные системы, объектно-ориентированное программирование.
В предлагаемой статье рассматривается уровень абстракций, который достаточно широкого применяется в программировании. Уровень абстракции представляет собой способ сокрытия деталей реализации определенного набора функциональных возможностей, который применяется для управления сложной проектируемой системы. Показано, что использование уровней абстракции в разработке операционных систем имеет особое место, так как декомпозиция системы весьма удобна для обработки и восприятия, при этом число уровней не должно превышать семи, так как на примере модели OSI можно убедиться, насколько усложнится задача при увеличении числа уровней абстракции.
Keywords: levels of abstraction, operating systems, object-oriented programming.
The article discusses the level of abstraction, which is wide used in programming. The level of abstraction is a way of hiding implementation details of a particular set offunctionality, which is used for the management of complex design systems. It is shown that the use of levels of abstraction in the development of operating systems has a special place, as the decomposition of the system is very convenient for processing and perception, with the number of levels should not exceed seven, as in the example of the OSI model, you can see how complicated the task by increasing the number of levels of abstraction.
В современном мире происходит интенсивная разработка программного обеспечения, что повышает требования к подготовке будущих инженеров-программистов. Один из аспектов, который требует пристального внимания это изучение рефлексивных и абстрактных способов мышления, особенно в курсах, посвященных гуманитарным аспектам программирования. В предлагаемой статье рассматривается уровень абстракций, который достаточно широко применяется в
программировании.
Один из путей приучения будущих специалистов к абстрактному мышлению — это изучение конкретных примеров программного обеспечения с целью понимания, имеющихся там уровней абстракции.
Рассмотрим первоначально общие понятия, а затем, конкретный пример использования данного механизма в разработке операционных систем.
Уровень абстракции представляет собой способ сокрытия деталей реализации определенного набора функциональных возможностей, который применяется для управления сложной проектируемой системы. При этом система подразделяется на несколько уровней. Детали нижних уровней-скрываются, дабы обеспечить верхним уровням более простые модели [1].
На самом нижнем уровне общение программиста с машиной осуществляется с помощью нулей и единиц. Так как это не совсем удобно, был изобретен более высокий уровень абстракции - язык ассемблера [2]. Но и этот язык оказался не совсем удобным в использовании, так как представлял собой символическую форму двоичного языка компьютера. Поэтому был создан еще более высокий уровень абстракции - язык программирования высокого уровня(ЯВУ). Сейчас уже насчитывается около сотни таких языков. К примеру, Basic, C, C++, Cobol и RPG.
И все-таки, первые языки программирования позволяли программисту абстрагироваться от конкретных машинных деталей и уменьшить количество уровней абстракции. Именно в этом причина их успеха. Фактически эти языки позволяли программисту работать почти на том же уровне абстракции, какой был в прикладной задаче. Дело в том, что задачи решались хорошо математически определённые, сложные в основном по логике, а математические объекты были самые элементарные -переменная, вектор, матрица. Для тех времён такой абстракции было вполне достаточно - и достаточно сейчас для решения большинства вычислительных задач.
При таком подходе программирование - это перенесение логики алгоритма на язык программирования, не более того. Всё сводится к логике.
Крупным достижением тех времён были подпрограммы [2]. Вызывая подпрограммы, программист абстрагируется от логики их выполнения. Если удачно разбить программу на подпрограммы, в каждой из них есть возможность работать на одном уровне абстракции - скажем, подпрограмма перемножения матриц имеет дело только с элементами. В головной же программе программист работает уже с матрицами, не опускаясь до уровня элементов, т.е. количество уровней абстракции уменьшается (точнее говоря, уменьшается не само количество этих уровней, а количество уровней, с которыми работает в данный момент программист). Именно в этом главное преимущество подпрограмм, но не все это понимают, и потому выделяют в подпрограмму обычно просто повторяющиеся действия, не связывая их с понятием абстракции. Возможно это тоже преимущество подпрограмм, но экономия сил в данном случае - не главный выигрыш. Если не выделен абстрактный объект, который "прячется" за подпрограммой, то эту
подпрограмму ждёт нелёгкое будущее - она либо не будет использоваться, либо будет бесконечно переделываться.
Если же понимать подпрограмму с точки зрения абстрагирования, то мы неизбежно приходим к иерархическому построению программы, соответствующему последовательному раскрытию абстрактных объектов. Майерс приводит следующие свойства этих уровней:
1. На каждом уровне не известно о свойствах и даже о существовании более высоких уровней.
2. На каждом уровне ничего не известно о внутреннем строении других уровней.
3. Каждый уровень представляется группой модулей.
4. Каждый уровень располагает определёнными ресурсами, которые скрывает от других уровней или представляет им некоторые их абстракции.
5. Каждый уровень может обеспечивать некоторую абстракцию данных в системе.
6. Предположения, которые на каждом уровне делаются относительно других уровней, должны быть минимальны.
7. Связи между уровнями ограничены явными аргументами.
8.Каждый уровень должен иметь высокую прочность и слабое сцепление.
Таким образом, прежде чем проектировать систему, нужно представить её иерархически. Это прямо вытекает из организации человеческого мозга. Он может манипулировать ограниченным количеством объектов (не более семи) и к тому же способен эффективно понимать одновременно не более двух уровней абстракции - текущий и предыдущий. Поэтому, если при написании программы углубиться в детали, чтобы реализовать некий сегмент, то потом, выйдя из него, с трудом можно вспомнить, зачем это было нужно. Нисходящий подход родился именно из этих соображений - нужно было найти путь такой, чтобы во время всего процесса проектирования находиться на одном уровне абстракции и манипулировать, возможно, меньшим количеством объектов. Подход хорош, но не идеален, так как выделять абстрактные объекты человек по природе не способен, и потому уровни абстракции распределяются в соответствии с логикой программы. Человек по-прежнему абстрагируется от логики программы, но, как правило, вынужден точно определять данные, проходящие через несколько сегментов программы. Поэтому уровни абстракции не получаются, получаются просто уровни подпрограмм. И, если в хорошо определённых математических задачах этот фокус проходит, так как там абстракция идёт в основном по логике, то для других задач - нет. В области численных задач был даже такой период, когда намечалось написание универсальных подпрограмм, которые останется только вызывать в определённом порядке.
Однако в целом этот метод не оправдался, так как программирование ушло от вычислительных задач и шагнуло к информационным, а тут уже на
первое место вышли не логика, а данные. И, если раньше задача была - при бедном наборе типов данных реализовать как можно больше функций над ними, то теперь - при довольно бедном наборе функций охватить как можно больше типов данных.
Все усилия в основном направлены на то, чтобы одну и ту же функцию распространить на разные типы данных, например, посчитать одномерную таблицу не только по дискретным предположениям, но и по непрерывным, и по символьным, причём уметь задавать какие-то структуры внутри этих данных - интервалы, автоматические и ручные, вот теперь группировка альтернатив и разные классы эквивалентности - при всём при этом функция остаётся та же - напечатать таблицу распределения частот.
На этом пути создаются всяческие языки, ориентированные на данные. Понятно, что используя достижения предыдущего этапа - от логики человек привычно абстрагируется подпрограммами. Однако и тут не предел развития - потому что на самом деле (без машины) человек (разработчик) работает не в терминах логики и/или данных - он оперирует с объектами, имеющими определённые свойства.
Можно предположить, что современное программирование идёт именно к этому. Уже достаточно очевидно, что фактически речь идёт об абстрактных типах данных, но предпочтительнее говорить о более широком понятии - объектно-ориентированном подходе к программированию. Это значительно шире, так как, кроме технических средств (языков и т.д.), здесь речь идёт и об изменении мышления программиста.
Разработка программы на языке высокого уровня является наглядной иллюстрацией многоуровневой абстракции. Компилятор преобразует программы на ЯВУ в язык ассемблера, который затем переводит команды в двоичный код, понятный для процессора. Необходимо заметить, что некоторые компиляторы генерируют команды уже непосредственно на машинном языке, минуя уровень ассемблера.
Перед выполнением программы на ЯВУ компилятор и ассемблер транслируют ее в команды машинного языка. Эта операция выполняется всего раз, и нет необходимости ее повторять при очередном запуске, если только исходный текст программы не был изменен. Наличие нескольких уровней позволяет скрыть детали нижележащего машинного языка от программиста, что уже было сказано ранее, и обеспечить более производительный и простой интерфейс.
Примерами моделей программного обеспечения, использующих уровни абстракции, являются семиуровневая модель OSI для протоколов передачи данных компьютерных сетей, библиотека графических примитивов OpenGL, модель ввода-вывода на основе потоков байтов из Unix, адаптированная MS DOS, Linux и многие другие современные операционные системы [3].
К примеру, в сетевой модели OSI содержится семь уровней абстракции:
1. Физический - самый нижний уровень абстракции этой модели, который отвечает за передачу данных, которые представлены в двоичном коде, от устройства к устройству. К нему относятся физические, механические и электрические интерфейсы между двумя системами. Все функции этого уровня реализуются на устройствах, подключенных к сети.
2. Канальный - уровень, предназначенный для обеспечения взаимодействия сетей на физическом уровне, а также выявления и исправления ошибок, которые могут возникнуть при этом. Полученные с нижнего (физического) уровня данные, упаковываются в кадры, проверяются на целостность, исправляются, если это необходимо, и только потом отправляются на уровень выше, на сетевой уровень.
3. Сетевой - уровень, необходимый для определения пути передачи данных, т. е. определения кратчайшего маршрута передачи данных от источника к получателю, отслеживания ошибок и «заторов» в сети, а также коммутацию и маршрутизацию.
4. Транспортный - уровень абстракции, необходимый для обеспечения надежной передачи данных. Но при этом необходимо учитывать, что уровень этой надежности может находиться в широких пределах. К примеру, существуют протоколы, осуществляющие только основные транспортные функции, например, без подтверждения приема данных, и протоколы, осуществляющие не только основные, но и дополнительные функции, такие как доставка нескольких пакетов данных в определенной последовательности, достоверность принятых данных и управление этими потоками данных.
5. Сеансовый - уровень, обеспечивающий поддержание сеанса связи и позволяющий приложениям взаимодействовать друг с другом длительное время. Также на этом уровне создается/завершается сеанс, осуществляется синхронизация задач, определяются права на передачу данных и поддержание неактивного сеанса.
6. Представительский - уровень, обеспечивающий преобразование протоколов и кодирование/декодирование данных. Этот уровень представляется как промежуточный протокол для преобразования информации, полученной из соседних уровней. Т. е. запросы приложений с прикладного уровня здесь преобразуются в формат для передачи по сети, а данные, полученные из сети, преобразуются в формат приложений. Также этот уровень абстракции форматирует и преобразовывает код, чтобы обеспечить приложению ту информацию, с которой он мог бы работать, и которая имела бы смысл, переводит данные из одного формата в другой. Еще одной функцией этого уровня является защита информации от несанкционированного доступа при пересылке. Для этого на этом уровне существуют подпрограммы, сжимающие текст и преобразовывающие графические файлы в битовые потоки для дальнейшей передачи по сути.
Соответственно, уровень представления отвечает за организацию и защиту данных при пересылке.
7. Прикладной - самый верхний уровень абстракции модели, который обеспечивает взаимодействие пользователя с сетью:
- осуществляет удалённый доступ к файлам и базам данных и пересылку электронной почты;
- отвечает за передачу служебной информации;
- предоставляет приложениям информацию об ошибках;
- формирует запросы к представительскому уровню.
Этот уровень содержит набор популярных протоколов, необходимых пользователям, к примеру протокол передачи гипертекста HTTP.
Типичное представление с точки зрения архитектуры компьютера системы в виде последовательности уровней абстракции:
1. компьютерная техника
2. прошивка
3. язык ассемблера
4. ядро операционной системы
5. приложения.
При этом необходимо упомянуть, что любой из протоколов модели OSI может взаимодействовать только с протоколами своего уровня и с протоколами на единицу выше и/или ниже своего уровня. Также любой протокол модели OSI может выполнять только функции своего уровня и никакого другого больше.
Причин, по которым модель OSI не была реализована не так уж и мало: - в связи с затянувшейся разработкой протоколов OSI, основным используемым стеком протоколов стал TCP/IP, разработанный ещё до принятия модели OSI и вне связи с ней и ни одна из компаний не стала поддерживать очередной стек протокол, ожидая, что это сделает кто-то другой;
- несовершенство разработанной модели, а том числе и ее протоколов. В результате этого два уровня (сеансовый и уровень представления) оказались пусты, в то время как два других перегружены (сетевой и передачи данных);
- сложность модели и протоколов, а также медлительность первых и последующих реализаций;
- неудачная политика тоже сыграла свою роль, т. к. разработчики пытались навязать исследователям и программистам неудавшийся в техническом отношении стандарт, что не способствовало продвижению этой модели.
Проанализировав вышесказанное, можно сделать вывод, что использование уровней абстракции в разработке операционных систем имеет особое место, так как декомпозиция системы весьма удобна для обработки и восприятия. В первую очередь восприятия разработчика. Также необходимо учесть, что число уровней не должно превышать семи, так как на примере модели OSI можно убедиться, насколько усложнится задача при увеличении числа уровней абстракции.
Но все-таки несмотря на все свои недостатки, модель OSI (кроме сеансового уровня и уровня представления) показала себя исключительно
полезной для теоретических дискуссий о компьютерных сетях.
Таким образом, мы вновь возвращаемся к утверждению, что уровни абстракции, как было сказано ранее, подталкивают нас к более обширному понятию как ООП (объектно-ориентированное программирование), где необходимо не только объектное мышление, но и верно выбранные уровни абстракции. Сделав это, разработчик уже может свободно представлять вещи в виде объектов и их взаимодействия, будь то реализация протокола, бизнес процесса или слоя доступа к базу данных. Соответственно, уровни абстракции весьма полезны для правильного представления и последующего решения поставленной задачи.
Литература
1. Программирование. Уроки и примеры. Ргс^гашт.^^ -электронные данные. - режим доступа : http://programm.ws/page.php?id=233, свободный.- Загл. с экрана
2. Солтис Фрэнк. Основы А8/400. [Электронный ресурс]. - Электрон. дан.(181 страниц). - СПб.: компьютерная литература, 1998. - Режим доступа: http://royallib.com/read/soltis_frenk/osnovi_AS400.html, свободный. - Загл. с экрана.
3. Орит Хазан, Джеймс Томэйко Рефлексия и абстракция в гуманитарных аспектах программирования [электронный ресурс]. - электрон. дан. (2страницы) — Открытые системы, №9, 2005 — Режим доступа: http://www.osp.ru/os/2005/09/380361/ свободный.- Загл. с экрана.
© Д. Николаев - студ. каф. автоматизированных систем сбора и обработки информации КНИТУ; Н. Староверова -канд. техн. наук, доц. той же кафедры, [email protected]; А. Хасанова - студ. той же кафедры.
© D. Nikolaev - r student, Department of automated systems of gathering and processing information, KNRTU; N. Staroverova -candidate of technical Sciences, Associate professor the same Department, [email protected]; A. Khasanova - student the same Department.
