Майк и его команда решили перепроектировать и переписать затронутые компоненты заново. Это было нелегким решением, так как большая часть низкоуровневого кода основывалась еще на первоначальном проекте System/38 и интенсивно настраивалась для повышения производительности в течение 15 версий системного ПО. Не все верили в успех: ведь предстояло полностью изменить лишь «начинку» переписываемых компонентов, оставив в неприкосновенности все интерфейсы, чтобы не затронуть переносимые компоненты. Кроме того, надо было учесть возможность расширений ПО в планируемых новых версиях AS/400. В общем, все это напоминало стрельбу по движущейся мишени.
Билл Берг — один из десяти специалистов, рекомендовавших использовать PowerPC для AS/400, — продвигал идею сократить время разработки, использовав объектно-ориентированное программирование (ООП). Объектно-ориентированные языки приобрели популярность конце 80-х как способ быстрого создания программ и уже были достаточно совершенными, чтобы использовать их в таком большом проекте. Билл Армстронг (Bill Armstrong) и Дик Мастейн (Dick Mustain) — также твердые сторонники объектно-ориентированной разработки — были с ним согласны. Пол Мэттисон (Paul Mattison) собрал команду и подготовил план действий. Поддержка ключевых разработчиков также доказала, что новая технология программирования поможет обеспечить делу успех. Кроме того, мы собирались нанять новых людей.
Концепции объектно-ориентированного программирования
Давайте кратко рассмотрим основные элементы и термины ООП. Объект — это основной элемент программы, объединяющий в себе данные и операции над ними. Операция, которую может выполнить объект, иногда называется методом. Внутренняя структура данных и реализация методов объекта скрыта от остальной программы. Это называется инкапсуляцией. Программе доступен только интерфейс объекта. ООП отличается тем, что объединяет операции и данные воедино (при процедурном программировании операции отделены от данных).
Подход ООП предполагает повторное использование ПО. Основной механизм обеспечения повторного использования — класс, представляющий собой шаблон, описывающий все объекты, для которых характерны одинаковые операции и элементы данных. Следовательно, может быть создано много объектов каждого из классов. Часто они называются экземплярами объекта.
Для существующего класса можно создать подклассы путем использования наследования. Наследование позволяет программисту и создавать новые подклассы, и повторного использовать код, а также данные базового класса без их повторения. Вновь полученные подклассы настраиваются так, чтобы соответствовать конкретным потребностям приложения. Способность подклассов одного класса отвечать на одно и то же входящее сообщение по-разному называется полиморфизмом. Полиморфизм объединяет концепции наследования и динамического связывания (dynamic binding).
Наборы объектов, созданные из классов и подклассов, могут быть объединены для построения необходимых сервисов ОС. После определения достаточно сложного набора классов (называемого библиотекой классов), программисты могут использовать классы этого набора, а не программировать заново функции, предоставляемые классами.
Однако в объектно-ориентированной технологии есть и недостатки. Производительность ядра ОС чрезвычайно важна, так как сильно влияет на производительность системы в целом. Исследования приложений для AS/400 показали, что значительная часть длинных цепочек команд приходится на код ОС. А при применении объектно-ориентированной технологии для некоторой функции повторно используется большое число маленьких модулей, и общая длина цепочек команд увеличивается, по сравнению с реализацией той же функции как единого целого. Группе пришлось включить в план работ время для выполнения тонкой настройки таких функций, чтобы сохранить показатели производительности ядра, достигнутые за предшествующие годы его разработки[ 29 ].
Среда разработки SLIC
Группа разработчиков должна была выбрать язык программирования. Язык программирования VLIC, называвшийся PL/MP и использовавшийся со времен разработки оригинальной System/38, был основан на языке PL/I. MP в его названии расшифровывается как Machine Product — имя, которое часто использовалось для обозначения аппаратных средств и обоих слоев микрокода. Компилятор PL/MP, как и ассемблер IMPI, генерировал двоичные машинные команды IMPI.
Язык PL/MP не пригоден для ООП, но его по-прежнему использовали для тех компонентов, которые не переписывались. А для остальных был разработан новый компилятор PL/MP, генерировавший двоичный код для PowerPC. Кроме того, было создано специальное средство переноса программ, которое сканировало код, отыскивая зависимости от IMPI, прежде чем преобразовать его в новый PL/MP.
В течение ряда лет мы пытались использовать другие языки при разработке компонентов VLIC. Например, один из наших новейших трансляторов был написан на Modula-2, применялся также язык С. Однако, мы чувствовали, что ни один из них не подходит для проекта, основанного на объектно-ориентированной технологии. Выбор напрашивался сам собой — язык C++. Нам нужно было разрабатывать код ОС очень низкого уровня. Иногда, для достижения оптимальной производительности приходилось прибегать к ассемблеру, и С+ + легче позволял это. Ведь, фактически, язык С++ и есть современный вариант ассемблера[ 30 ].
Другим преимуществом С++ была возможность легко найти людей, его знающих. Для этого проекта нам было нужно много новых программистов, и начался массовый найм. Скоро над проектом SLIC работало более 200 человек.
Для успеха проекта обучения было крайне важно, чтобы вновь набранные сотрудники поскорее изучили внутреннее устройство AS/400[ 31 ], а наши старые работники — программировать на С++. Некоторые уже умели это, но большинство из них использовали С++, как улучшенный С. Нужно было научить каждого объектно-ориентированному подходу. Это стало настоящей проблемой, так как в Рочестере на тот момент не оказалось никого, кто зашел бы дальше прочтения нескольких книг по данной теме. Решение было предложено Крисом Джонсом. Согласовав свои действия с другими руководителями проекта, он нашел стороннего консультанта — эксперта как в объектно-ориентированной технологии, так и в программировании на С++. Никогда ранее мы не обращались «на сторону» по подобным поводам. У IBM были внутренние программы обучения, и персонал, который этим занимался. Разумеется, приглашение на работу чужака было воспринято в штыки. Крис настаивал и убедил-таки руководство нанять консультанта для интенсивного шестинедельного обучения наших сотрудников. Мы даже специально выгородили прямо посередине отдела разработки классную комнату, которая использовалась исключительно для обучения.
Возможность повторных итераций при разработке — фундаментальное преимущество ООП, но при ее использовании трудно оценить, в какой степени мы продвинулись вперед. Прием, который мы использовали для «измерения прогресса», заключался в так называемых BUB (Bring up Bind). Каждый BUB представлял собой группу объектов, реализовывавших четко определенный набор функций ОС, и имевшую общий интерфейс с другими компонентами. Путем сравнения BUB с другими компонентами, мы могли оценить, как продвигается разработка. Кроме того, BUB позволили нам действовать в определенном порядке, а также вызвали переделку известного рекламного лозунга Budweiser: «This BUB's for you»[ 32 ].
Технология ООП не подвела: производительность программистов при разработке SLIC повысилась почти в четыре раза по сравнению с традиционной методикой. В период с июля 1992 года, было создано более миллиона строк кода на С+ + и более 7 000 классов. Считая весь перенесенный код, ниже MI работает более 3 миллионов строк кода ОС.
Затраты на разработку SLIC
Создание вычислительной системы с высокоуровневым машинным интерфейсом и значительной частью ОС, расположенной под этим интерфейсом, было связано с определенными затратами. На разработку ПО пришлись основные расходы, связанные с AS/400. Давайте ненадолго остановимся и рассмотрим, почему так получилось.
SLIC содержит 3 миллиона строк надежного кода. (Под надежным имеется в виду код, который всегда должен работать правильно, чтобы обеспечить целостность и защищенность системы.) Так как SLIC — ядро ОС, мы не защищаем один его компонент от другого. Это совершенно обычный подход: ядра большинства ОС защищены от кода, расположенного вне его, но весь код внутри ядра считается надежным.
Если ядро невелико, скажем, состоит из 100 тысяч строк кода, то его целостность очень легко протестировать при каждом изменении. Если же строк 3 миллиона, то такое тестирование становится и сложнее, и дороже. Много лет мы в Рочестере использовали следующий подход: строго ограничивали круг тех, кому позволено работать с ядром, группой разработки и тестирования. Таким образом, код для SLIC могут написать заново только разработчики из Рочестера (впрочем, это достаточно большое число людей). Дополнительно надежность гарантируется тем, что разработчики действуют в условиях жесткой организационной структуры.
