Компания IBM
Опубликован: 28.08.2008 | Доступ: свободный | Студентов: 460 / 64 | Оценка: 4.33 / 4.05 | Длительность: 31:19:00
Лекция 6:

Объекты

< Лекция 5 || Лекция 6: 12345 || Лекция 7 >
Аннотация: Объекты предоставляют средства управления и защиты системных ресурсов AS/400. Правила именования и адресации практически всех элементов системы привязаны к объектам. Эта лекция будет посвящена объектам.
Ключевые слова: Интернет, Java, отношение, simula, операции, Unix, SUN, NEXT, system, ПО, компьютерное моделирование, Ada, object orientation, наследование, подкласс, объект, контейнер, целостность, коды операций, процессор, программа, MVS, файл, вирус, группа, output queue, job queue, информация, API, пространство, базы данных, facility, системный объект, ясность, эквивалентные объекты, контекст, очереди сообщений, очередь заданий, дамп, курсор, база данных, индекс, доступ, представление, управляющие, буфер, функция, поиск, SAM, связанный список, vision, NetWare, network file system, EBCDIC, binary code, компонент, SLIC, адрес, однократный доступ, способ адресации, поиск объектов, resolvability, рабочее пространство, IPL, память, параметр, дополнительные расходы, загрузка, расходы, производительность, время выполнения, слово, диск, единое адресное пространство, физическая структура, EPA, encapsulated programming, свойства программы, powerpc, атрибут объекта, сборка мусора, определитель, Двоичное дерево

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

Подобно другим технологиям, которые мы считаем новыми, объекты используются в программировании уже более 30 лет. Впервые они появились в конце 60-х годов в языках типа Simula 67, применявшихся для программ моделирования. Современные языки программирования, такие как Java, C++ и Smalltalk — прямые потомки Simula 67. Программы моделирования имитируют поведение объектов реального мира. Аналогично, прикладные программы для бизнеса, содержащие объекты и операции над ними, моделируют реальные деловые отношения.

ОС работают с аппаратными и программными объектами, такими как устройства ввода-вывода и программы. Использование объектов в ОС выглядит совершенно естественным. О создании объектноориентированной ОС говорят многие фирмы, такие как Microsoft, Apple, Novell/USL (UNIX Systems Laboratory) и Sun Microsystems, однако, лишь немногие из них смогли реализовать свои планы. Одна из таких фирм — Next, уже поставляющая на рынок объектноориентированную ОС под названием NextStep.

Есть, конечно, и другая объектноориентированная ОС. С момента появления System/38 мы строим ОС (CPF и OS/400) по объектноориентированной модели1Некоторые из нас, создателей System/38, были очень хорошо знакомы с языками компьютерного моделирования уже в конце 60-х. Я сам использовал объектные модели в своей докторской диссертации для компьютерного моделирования различных архитектур виртуальной памяти. Решение использовать объекты в System/38 пришло после нашего участия в проекте Future Systems (подробнее об этом см. в Приложении).. Более того, мы не остановились на этом, но сделали объекты фундаментальной частью архитектуры машины. Как уже отмечалось в "Машинный интерфейс, независимый от технологии" , MI состоит из двух частей: команд и объектов. В этой лекции мы рассмотрим использование объектов в AS/400.

Иногда говорят, что AS/400 это не объектноориентированная система, а система на основе объектов (objectbased). Различие этих двух терминов имеет смысл при обсуждении языков программирования. Например, есть языки на основе объектов, такие как Ada, и объектноориентированные языки, такие как Smalltalk-80. Гради Буч (Grady Booch) определил различия между этими двумя типами языков. По Бучу, в языке на основе объектов отсутствует наследование2Grady Booch. Object Oriented Design with Appliations. The Benjamin/Cummings Publishing Company, Inc. 1991.. Как уже вкратце упоминалось в "System Licensed Internal Code (SLIC) — сердце AS/400" , наследование определяет иерархию классов, где подкласс заимствует структуру или поведение одного или нескольких базовых классов. Наследование позволяет создавать новые типы объектов. Так как объекты AS/400 ничего не наследуют от других объектов, и прикладные программисты, пишущие приложения для этой системы, не могут создавать новые типы объектов, то вероятно, правильнее называть AS/400 системой на основе объектов. Но какое бы имя мы не выбрали, важно то, что AS/400 не просто использует или включает объекты, — они являются фундаментальной частью ее архитектуры.

В упрощенном виде объект — это просто контейнер, внутри которого находятся пользовательские и системные структуры данных. Объект инкапсулирован, что означает (как мы условились ранее) невозможность заглянуть внутрь него. Система, построенная на основе объектной модели независима от аппаратуры. Первопричиной использования объектов в System/38 было желание инкапсулировать детали, чтобы позже их можно было изменять без влияния на прикладные программы.

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

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

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

Итак, мы были очень обеспокоены проблемами целостности, и сделали все, что бы таковых не возникало в AS/400. Команды в этой системе могут работать только с теми объектами, для которых предназначены. Некоторые универсальные команды, такие как "Создать объект", применимы ко всем объектам, другие — работают только с объектами определенных типов. Таким образом, в AS/400 нельзя использовать объект не по назначению, как в обычной системе. В результате целостность значительно повышается.

На эту проблему можно взглянуть и с другой стороны. В большинстве ОС, все, что находится в постоянной памяти, считается файлом (в MSDOS или MVS файлом называют набор данных). Файлы могут иметь различное назначение, но такая классификация определяется лишь по соглашению. Вы можете читать объект-программу так, как если бы это был файл. В OS/400 это невозможно (как и создать вирус, по крайней мере, в слое над MI), так как термин "файл" применим лишь к небольшому числу типов объектов, и программа определенно файлом не является. Кстати, с этим связаны некоторые неудобства, присутствовавшие в System/38, где значительная часть информации об объектах была недоступна программам. COMMON (группа пользователей AS/400) многократно просила включить во все команды отображения, такие как, например, "DSPOUTQ" ("Display Output Queue"), "DSPJOBQ" ("Display Job Queue"), опцию генерации выходного файла, чтобы информация, хранящаяся внутри объектов, могла быть считана программно. В конце концов, мы добавили такую возможность в некоторые команды, которые первоначально ей не обладали (а в "DSPOUTQ" и "DSPJOBQ" ее нет и сейчас). Но исчерпывающим ответом на эти запросы было создание API, позволяющих поместить информацию об объектах и системе в объект, известный как пользовательское пространство. Этот объект программы могут читать быстрее, чем файлы базы данных.

Имена объектов

В System/38 объекты были как в ОС, так и в MI. Определением этих объектов и выбором имен для них занимались две разные группы. Одна разрабатывала объекты CPF, (которая в AS/400 была переименована в OS/4003До AS/400 в системах Рочестера не использовалось название "операционная система". Считалось, что для большинства заказчиков ОС — это нечто слишком сложное и страшное, а такие названия, как Control Program Facility и System Support Program, казались более близкими. К нашему большому изумлению, при объявлении DOS (Disk Operating System) для IBM PC никто не испугался. Поэтому мы решились на название OS/400. ), другая — разрабатывала набор команд и системные объекты MI.

Хорошо, что иногда между объектом OS/400 и объектом MI соотношение один к одному, тогда это тот же самый объект. Все усложняется, когда это разные объекты. Все объекты OS/400 состоят из одного или нескольких системных объектов MI. Другими словами, типы объектов OS/400 и типы системных объектов MI соотносятся как один к одному или как один ко многим, но никогда как многие к одному или многие ко многим.

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

Иногда, объекты OS/400 и системные объекты MI, даже при соотношении между ними один к одному, могут называться поразному. Например, в OS/400 есть объект "библиотека", в MI эквивалентный объект называется "контекст". Как это могло получиться? Ответ восходит ко времени создания System/38 двумя разными группами проектировщиков с разными подходами к выбору названий.

Один подход таков: коль Вы создаете новую систему — то все надо переименовать, и пусть пользователи, видя новые названия вдумаются в новую структуру. По этой логике, если Вы собираетесь реализовать библиотеку и назвали ее библиотекой, то кто-нибудь обязательно скажет: "Я знаю, что такое библиотека; я уже работал с системой, где есть библиотеки". Между тем, библиотека в другой системе может полностью отличаться от Вашей. Если же дать библиотеке другое название, например "контекст", то никто не сможет априори строить о ней какие-либо предположения. Данный подход к именам защищал Гленн Хенри — менеджер программирования System/38 и, следуя подобным взглядам, группа, разрабатывавшая системные объекты MI, породила некоторые весьма странные названия.

Названия же для объектов ОС выбирала другая группа, предпочитавшая под ход Томаса Эдисона (Thomas Edison): лучше даже не вполне подходящее, но уже знакомое покупателям имя. Когда Эдисон продвигал идеи использования электроэнергии, он решил выбирать названия, знакомые каждому, использующему природный газ. Он говорил, что к дому подводятся электрические магистрали (main), подобно газовым или водопроводным магистралям, хотя main — это труба или канал, а электроны, обычно, попадают в дом не по трубе. Он также называл нагревательный элемент кухонной плиты электрической горелкой, чтобы электрическая плита казалась чем-то знакомым людям, имевшим дело с газовыми горелками (скажем честно — электричество в нагревающем элементе не "горит"). Наша группа разработчиков ОС понравилась бы Эдисону.

Объекты OS/400 и системные объекты MI

Несколько типов объектов имеются и в OS/400, и в MI. Типы объектов OS/400 перечислены в таблице 5.1. Для сравнения, в таблице 5.2 приведены системные объекты MI. Помните, что в каждой новой версии AS/400 добавляются новые функции и даже новые объекты. Списки объектов таблицах 5.1 и 5.2 достаточно полны для нашего обсуждения в этой и "Интегрированная база данных" , но включить в них все типы объектов невозможно.

Таблица 5.1. Объекты OS/400
Графический набор символов Служебная программа
Документ Описание сетевого интерфейса
Идеографическая таблица символов Описание сессии
Идеографическая таблица сортировки Описание подсистемы
Идеографический словарь Словарь правописания
Индекс поиска информации Таблица
Класс Библиотека
Класс описания сервиса Описание линии
Команда Определение меню
Область данных Определение группы панели
Описание задания Пользовательский индекс
Описание контроллера Очередь сообщений
Описание редактирования Программа
Описание устройства Модуль
Очередь данных Определение продукта
Очередь заданий Пользовательский профиль
Папка Справочная таблица трансляции кода
Словарь данных Описание режима
Список документов Выходная очередь
Список конфигурации Файл сообщения
Список прав Журнал
Таблица управления формами Описание машины S/36
Файл Определение запроса
Формат диаграммы Приемник журнала
Таблица 5.2. Системные объекты MI
лок транзакции Описатель режима
Группа доступа Индекс
Индекс пространства данных Очередь
Класс описания сервиса Описание логического устройства
Контекст Модуль
Курсор Пространство управления процессом
Описание контроллера Описатель сети
Пространство дампа Профиль пользователя
Пространство данных Программа (3 подтипа)
Пространство цепочки байтов Пространство журнала
Словарь Пространство
Список прав Порт журнала

Некоторые объекты OS/400 из таблицы 5.1 полностью соответствуют системным объектам MI из таблицы 5.2, при этом имена объекта в двух разных наборах могут совпадать, а могут и не совпадать. Пример совпадения имен — "программа", несовпадения — "библиотека" и "контекст".

Другие объекты OS/400 относятся к системным объектам MI как один ко многим. Посмотрите на пример на рисунке 5.1: здесь файл базы данных OS/400 состоит из пяти системных объектов MI, и ему соответствуют четыре разных типа системных объектов MI (в нашем примере два объектапространства). Фактически, файл могут составлять намного больше объектов. Для каждого из них существует курсор, и даже однокомпонентный файл объединения (join file) может владеть или ссылаться на 32 индекса области данных. База данных, а также связи между разными системными объектами MI будут рассмотрены в "Интегрированная база данных" .

Объекты файла базы данных OS/400

Рис. 5.1. Объекты файла базы данных OS/400

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

< Лекция 5 || Лекция 6: 12345 || Лекция 7 >
Александр Качанов
Александр Качанов
Япония, Токио
Олег Корсак
Олег Корсак
Латвия, Рига