`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Palm OS -- программистские тайны успеха

0 
 

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


Скорость

Когда речь заходит об устройствах под управлением Palm OS, скорость в "персонально-компьютерном" понимании этого слова практически никого не интересует. Процессоры со смехотворно низкой тактовой частотой и мизерные объемы памяти (естественно, все вышеперечисленное справедливо только в сравнении с настольными ПК) позволяют сразу исключить всякие оценки производительности из нашего разговора. А вот под "скоростью" мы будем понимать темпы развития самого проекта Palm, а именно его программной составляющей.

Первая версия Palm OS увидела свет в 1996 г. Она использовалась в устройствах-первенцах -- моделях Pilot 1000 и Pilot 5000. С этого момента до сегодняшнего дня прошло на самом деле не так много времени, за которое разработчики Palm OS успешно преодолели следующие этапы: существенно модифицированная версия 2.0 с радикальными изменениями пользовательского интерфейса (далее -- UI, User Interface); версия 3.0 -- опять радикальные изменения UI. Их перечень включает в себя динамический характер интерфейсных элементов и усовершенствованную поддержку шрифтов; версия 3.1, обязанная своим появлением использованию нового процессора (Motorola Dragonball EZ) и... резкому росту популярности платформы Palm, -- именно начиная с этой версии Palm OS приобрела совместимость кодировок символов с Microsoft Windows (до этого в наладонных компьютерах семейства использовались собственные кодовые таблицы); версия 3.2 -- реакция на возросшую пользовательскую базу -- так называемый bugfix-релиз, включающий исправления обнаруженных пользователями ошибок; версия 3.5 -- второе радикальное перестроение системы, поддержка цветности и важнейших внутренних механизмов ОС; естественная реакция на радикальность изменений -- три bugfix-релиза (3.5.1, 3.5.2 и 3.5.3); наиболее распространенная на сегодняшний день версия 4.0, куда входит поддержка только появлявшихся в проектах адаптеров Bluetooth и так называемых устройств "вторичной памяти" -- накопителей на основе технологии Flash-памяти; bug­fix-релиз 4.1 (сюда же можно отнести и ожидающийся, но еще не вышедший релиз 4.2); и наконец, эпохальная версия 5.0, на которой "обкатываются" решения по сохранению наработанного ПО при полном изменении аппаратной платформы. Более чем неплохой результат, достигнутый всего за семь лет, особенно если учесть завоеванную Palm-совместимыми устройствами популярность и далеко не низкое соотношение цена/характеристики даже для бюджетных моделей Palm.


Главная тайна

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

Однако не все так просто. Реалист Фредерик Брукс, заслуженно признанный классик управления крупными (мягко говоря, даже по сегодняшним меркам) программными проектами, некогда ознакомил "современных колдунов" со "страшным откровением" -- всегда выгоднее купить готовую реализацию, чем разрабатывать ее аналог самостоятельно. И пока речь ведется об инструментальных средствах, библиотеках или готовых компонентах будущего программного проекта, в справедливости правила "купить все, что можно" сегодня мало кто сомневается. Но мы не случайно завели речь о важности ядра ОС, и пора к приведенному короткому списку разных (Windows NT -- гигансткая корпоративная разработка, ОС Linux -- результат работы свободного сообщества, QNX -- нишевая ОС, созданная и поддерживаемая небольшой компанией), но удачных проектов добавить еще один -- радикально от них отличающийся самой важной деталью, а именно Palm OS, созданную на основе правила Брукса "в целом и основном". На сегодняшний день это одна из очень немногих операционных систем, добившихся коммерческого успеха и использующих лицензированное ядро. Сама компания Palm ядра своей ОС не разрабатывала, его автор (оно называется AMX RTOS) -- небольшая компания KADAK, специализирующаяся на создании ПО для встраиваемых (embedded) систем.

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


Философия

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

Palm OS -- программистские тайны успеха
Рис. 1
По сути, "философию" проекта Palm OS можно назвать не иначе как здравым смыслом. Идеологическая основа основ системы не изменялась на протяжении всей ее короткой, но бурной истории, и излагается крайне кратко -- в виде диаграммы, иллюстрирующей различие между характером работы пользователей ПК и КПК (рис. 1).

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

Предположение специалистов Palm о характере использования КПК стало точкой отсчета системы координат, в которой формировались requirements -- требования к будущей системе. В их перечень входили очевидные следствия из предположения -- из-за непродолжительности сессии работы ощутимое время загрузки (или выхода из режима пониженного энергопотребления) устройства недопустимо; частые сессии требуют высокой энергетической эффективности устройства; короткая сессия означает потребность в механизмах быстрого ввода информации. Первым двум requirements в сегодняшних Palm практически идеально соответствует специфика внутренней организации операционной системы и выбор аппаратных средств, а вот последнее требование было воплощено в знаменитой и злополучной системе распозна­вания рукописных символов -- Graffiti. О ней стоит сказать особо -- строгость requirements ставила перед разработчиками крайне противоречивые задачи: с одной стороны, высокая энергетическая эффективность вынуждала выбирать малопотребляющий процессор с низкой тактовой частотой, с другой -- надежный механизм распознавания вводимых символов требовал большой вычислительной мощности. Система Graffiti, как компромиссное решение, компенсировала недостатки аппаратно-программных средств повышенными требованиями к пользователю -- ему приходилось обучаться новым (по сути -- стенографическим) начертаниям символов. Практика показала, что именно такой компромисс оказался очень удачным.

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

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


Архитектура

Принцип "хуже -- это лучше" (worse is better), слава Богу, никакого отношения к мрачным антиутопиям Оруэлла не имеет. Это всего лишь один из инженерных архитектурных принципов, сформированных в нематериальной (программной) инженерии. Ричард Габриэль в своей знаменитой статье, посвященной языку программирования Lisp, так охарактеризовал "worse is better": простота, корректность, логичность и полнота. Мы воспользуемся и этим определением, и все-таки не преминем вспомнить о подозрительной схожести с оруэлловским "война -- это мир".

Palm OS -- программистские тайны успеха
Рис. 2
Несмотря на более чем скромный размер реализации, архитектура Palm OS (рис. 2) соответствует представлениям о весьма современной операционной сис­теме. Здесь есть и слой, абстрагирующий аппаратные средства (HAL -- Hardware Abstraction Layer), и поддерживающее многозадачность ядро реального времени с разделением ресурсов посредством семафоров, обеспечивающее многоуровневую обработку прерываний (вложенные прерывания). В области важнейших системных сервисов следует отметить менеджер обмена сообщениями, поддерживающий "общение" между различными задачами и операционной системой, а также менеджер памяти.

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

В соответствии с этим правилом в архитектурных решениях Palm OS масса тонких и сложных нюансов тщательно спрятана от прикладного программиста -- это касается и обработки ошибок (точнее, перехвата сообщений об ошибочных ситуациях), роль которой фактически выполняет механизм прерываний, переключение задач на деле является передачей управления подпрограммам. В связи с тем что интерфейсы ядра ОС "упрятаны", доступ к функциональности системы осуществляется посредством посылок сообщений менеджерам, два из которых мы уже упомянули -- сообщений и памяти. Всего же в системе насчитывается десять менеджеров, охватывающих все аспекты функционирования КПК -- от инициируемых часами реального времени событий (оповещений, напоминаний и пр.) до многопротокольного транспорта данных (Tcp/Ip, IrDA, Bluetooth). Некоторые решения, очевидно необходимые для развитой операционной системы, в Palm OS вообще упрощены "до безобразия". Так, уникальность идентификации приложений, позволяющая, с одной стороны, установить соответствие между специфическими для них форматами данных и обрабатывающими их программами, с другой -- сформировать некоторое подобие компонентной среды в системе, основана на централизованном принципе -- сама компания Palm ведет базу данных таких идентификаторов (в терминах Palm OS -- Cre­ator ID), регистрируя в ней каждую прикладную программу. Процедура регистрации максимально упрощена, Creator ID представляет собой ASCII-строку из четырех символов -- и все это для того, чтобы избежать одного неприятного момента -- совпадения Creator ID двух разных программ, обрабатывающих разные типы данных. В этом случае при установке таких программ на любой Palm-совместимый компьютер пусть не очень серьезных, но все же малоприятных проблем не избежать. Второе ключевое упрощение связано с нюансами управления памятью в компьютерах, имеющих в своем аппаратном арсенале только RAM (память с произвольным доступом). Все дело в том, что разработчики Palm изначально отказались от идеи "области времени выполнения" (runtime RAM) -- динамически выделяемой части ОЗУ, предназначенной исключительно для временного хранения обрабатываемых данных и промежуточных результатов. Соответственно, в Palm OS информация модифицируется прямо по месту хранения -- это и хорошо, и одновременно не очень: с появлением версии 3.0 система перестала страдать фрагментацией памяти, и Palm OS обрела эффективный механизм управления данными.

"Обоюдоострость" архитектуры, основанной на принципе "worse is better", заключается в создании простой (с точки зрения стороннего разработчика) операционной среды, одновременно соответствующей жестким изначальным требованиям. Быстрый, взрывоподобный рост и рынка сбыта Palm-совместимых КПК, и рынка ПО для них -- лучшее тому доказательство. Компактность кода системных сервисов и их нетребовательность к ресурсам можно проиллюстрировать следующими характеристиками Palm OS: работающей системе нужны области памяти размером 96 KB для хранения общесистемных глобальных переменных (в которые входит и буферная память экрана), 32 KB -- для функционирования Tcp/Ip-стека, 4 KB -- для стека приложений и локальных переменных и 36 KB -- для системной поддержки приложений. Цифры, конечно, по сегодняшним меркам смешные.

Этот короткий обзор был призван продемонстрировать только одно соображение -- правило "worse is better" нельзя игнорировать. Даже исключительно простые архитектурные решения могут оказаться успешными, даже таящие потенциальную опасность методы (например, метод обеспечения уникальности Сreator ID, о нарушении которого автору еще не доводилось слышать) могут в реальных условиях работать совершенно безопасно.


Явный метаалгоритм

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

Palm OS -- программистские тайны успеха
Рис. 3
Метаалгоритм работы КПК Palm является овеществлением философии проекта, представленным в виде глобальной диаграммы состояний устройства. Конечно, можно было бы отнести эту диаграмму просто к необходимой документации, но на деле ее роль куда более важна -- она не просто ограничивает полет фантазии разработчика (что само по себе в любом реальном проекте неплохо), а создает конкретную макромодель работы всего программно-аппаратного комплекса, каким является портативный компьютер. Оказывается, эта модель крайне проста (рис. 3): "машинка" может находиться в любой момент времени в одном из трех состояний -- "сна" (Sleep), "дремы" (Doze), "выполнения" (Running). Перевод ее из состояния в состояние может инициироваться пользователем или программно-аппаратными средствами. Находящийся в "обычном" состоянии "сна" (работают только часы реального времени, цепи генерации прерываний и схема регенерации ОЗУ) КПК может быть "разбужен", но, в отличие от жестоких армейских правил, ласково -- ему дается возможность "подремать" (включаются периферийные цепи и начинается ожидание пользовательского ввода). Состояние "дремы" резко уменьшает время реакции -- ведь большая часть электроники запитана, и только процессор не выполняет инструкций. Теперь любое действие пользователя может активировать режим "выполнения", запускающий процессор. В этом режиме, если пользователь ничего не делает некоторое время, КПК автоматически впадает в "дрему" или вообще "засыпает". Благодаря такой функциональной модели секунды экономии батареи питания в состоянии "дремы", складываясь, приводят к существенному снижению энергопотребления, пользователь получает почти мгновенную реакцию устройства на свои действия, а разработчик -- четкую инструкцию и видение проекта "в целом".

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


И большая ложка дегтя...

Любой успех -- понятие очень временное. А вот любой успешный программный проект -- понятие тоже очень, но долговременное. Те очевидные вещи, о которых мы говорили, привели компанию Palm к быстрому (семь лет для сегодняшней компьютерной индустрии, сытой историями звездных стартапов-скороспелок, -- это уже достаточно быстро) успеху. Теперь в истории компании и ее продуктов начинается период борьбы за его сохранение. Сложный и поучительный для тех, кто предпочитает учиться на чужих ошибках, период. И даже в его начале становятся понятными куда менее приятные аспекты некоторых составляющих успеха. Принцип "worse is better" в долговременной перспективе оказывается не таким уж и привлекательным -- минимализм, навязанный им, и столь необходимый на раннем этапе становления продукта, сегодня играет роль ограничителя (если не сказать грубее -- тормоза). Чтобы убедиться в этом, достаточно сравнить перечни прикладного ПО, входящего в стандартную поставку современных КПК двух разных классов, но практически одного ценового диапазона -- Palm и агрессивно борющейся за рынок платформы Pocket PC. Что хуже, "worse is better" начинает приобретать оруэлловский смысл -- пользователи, оказывается, готовы мириться с ненадежностью ПО КПК (это оправдано сверхскоростной перезагрузкой устройства и некритичностью решаемых с его помощью задач), но вот с необходимостью приобретать те приложения, которые можно получить "за бесплатно", они мириться не хотят. Ставка на совершенство одной подсистемы (в случае Palm эта подсистема -- Graffiti), оказывается, весьма рискованна, расчет на одну сильную карту (энергопотребление) недостаточен для долгой игры (этот показатель у современных КПК двух противостоящих классов практически идентичен)... То, о чем мы говорим сейчас, увы, не поддается четкой формализации. Это уже искусство -- то самое, определяющее грань между успехом и победой...
0 
 

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT