"Железный" GUI
"Железный" GUI
Андрей Зубинский
Компьютерное Обозрение, 18-24 ноября 2003
Так уж мы устроены, что нечасто задумываемся о вещах совершенно обыденных.
И это абсолютно нормально. Но иногда "обыденность" вещей скрывает нечто
не просто очень интересное, но важное и нужное. А то, что важно и нужно, простите
за прозаичность, измеряется уже больше в деньгах, чем в эмоциях...
Проблема # раз
Область использования графических пользовательских интерфейсов (GUI), сколько
бы ни скрежетали зубами адепты "шаманизации" технологий, уже давно вышла
за пределы программ для универсальных, "бытовых", ПК. Использованное
здесь жесткое выражение -- не "новояз" и не образчик чего-то исключительного.
"Шаманизация" подразумевает идею недоступности высшего божества Технологии
"простым смертным" и, соответственно, требует института Посвященных
-- жрецов, выделяющихся признаками кастовой принадлежности (будь то ритуальные
бубны или белые халаты смены операторов вычислительного центра).
Включая утром микроволновую печку и совершенно автоматически следя за показаниями
жидкокристаллического или люминесцентного индикатора, мы даже не представляем
себе в силу очевидности этих действий, что, во-первых эти действия далеко не всегда
были настолько очевидны, во-вторых, вполне допустима микроволновая печь
со 101-клавишной клавиатурой и "мощной расширенной системой команд",
но для свершения ею чуда -- разогрева чашки чая -- надо учить "заклинания",
известные только "жрецам". К счастью, в реальности "во-вторых"
остается только допущением...
Но довольно метафор и аллегорий. Удобный, "прозрачный" и понятный GUI
нужен пользователям. Причем пользователям самых разных устройств -- прежде всего,
достаточно сложных и специализированных, как это ни кажется странным на первый
взгляд (ведь именно такие пользователи всегда считались "белыми воротничками",
нижним слоем пирамиды технической элиты). Универсальная вычислительная техника
-- дело особое, здесь вполне допустима проверенная историей модель цивилизованного
обмена услугами между специализирующимися в разных областях людьми или группами
людей (не надо путать ее с "шаманизацией"). А вот современные сложные
машины и приборы во всех их разнообразных проявлениях -- это уже серьезная проблема.
Да, их пользователи относятся к классу технической элиты. Но именно поэтому им
некогда и незачем заниматься чем-то отдаленным от основной специальности. Конечно,
эти люди могут найти и время, и силы, и наконец, средства (не зря же они все-таки
"элита") на изучение чего-то совсем "стороннего", но только
в случае реальной и обоснованной необходимости. А вот времена, когда эта необходимость
была таковой, безвозвратно прошли.
Проблема # два
Мы только что попробовали бросить беглый
взгляд на GUI с точки зрения пользователя, относящегося к "технической элите"
(о "просто пользователе" речь вообще не идет в силу очевидности) и задействующего
сложную машину или прибор (инструмент) в каком-то технологическом (научном или
ином) процессе. Но есть категория пользователей (да-да, именно "пользователей"),
для которых результатом такого технологического процесса является собственно GUI
-- как программное изделие или элемент какой-то завершенной разработки. "Выбросить"
этих пользователей из обсуждения -- уже дискриминация. И хоть их принято гордо
называть "программистами", на самом деле их работа также сводится к
грамотному и эффективному применению сложных инструментов и "приборов"
-- алгоритмов, ассемблеров и языков высокого уровня, трансляторов, интегрированных
сред разработки, генераторов кода и т. д.
Естественно, специалисты этой категории не оставлены без внимания. Времена "гуру"-разработчиков
GUI, способных реализовать чуть ли не "с нуля" GUI-подсистему, канули
в Лету. В избытке существуют библиотеки специфических для решения задач GUI подпрограмм
и классов, GUI-Builders (генераторы GUI-кода), RAD-инструменты (Rapid Application
Development), средства прототипирования и т. д. Это действительно замечательные
вещи, но, как положено, не всегда настолько замечательные, чтобы быть совершенно
универсальными.
Проблема # три
Пока мы говорим об универсальных (т. е.
более чем мощных на сегодняшний день) компьютерах, весь инструментальный набор
"мастеров GUI" вполне адекватен и возможностям техники, и запросам потребителей.
Да, библиотеки функций и классов становятся все громаднее. А почему бы, собственно,
и "нет" -- ведь заведомо неизвестно, что понадобится пользователю, известно
только, что "аппетит приходит во время еды". Да, GUI-builders и RAD
становятся все сложнее, и по той же причине.
А как же быть в случае встраиваемых устройств? Тех самых "компьютеров-невидимок",
упрятанных чуть ли не во что угодно -- от копеечного электронного будильника,
микроволновки, стиральной машины до диагностического центра на станции технического
обслуживания автомобилей, электронного микроскопа или кардиомонитора. Дело даже
не столько в том, что современные, унаследованные из "универсальной технологии"
GUI-подсистемы неадекватны возможностям используемых в такой технике вычислителей
(хотя, несомненно, "утрамбовать" объектно-ориентированный GUI в ограниченные
объемы памяти ходовых 8- и 16-битных микроконтроллеров, да еще и добиться от получившегося
приемлемой производительности -- задача далеко не тривиальная и в общем случае
неразрешимая). Тут проблема куда неприятнее и сложнее -- GUI-подсистема плохо
"вписывается" в жесткие (или даже "жестокие") требования к
надежности вычислителя. Ведь не секрет, что GUI и "сложность" -- синонимы,
а "сложность" и надежность -- антонимы. Во встраиваемых системах со
"смешными" ресурсами вычислителей и традиционными требованиями к "реальности
масштаба времени" это противоречие приобретает угрожающие формы: программисты
должны заботиться и о главной функциональности вычислителя, строго определенной
принципами работы управляемого устройства, и еще стараться "позаботиться"
о пользователе. Иногда противоречие разрешимо, но в терминах индустрии понятие
"иногда" неприемлемо. Увеличение ресурсов встраиваемого вычислителя
также не всегда допустимо даже при учете постоянного снижения цен на полупроводники
хотя бы потому, что закон сохранения энергии еще никто не отменял, а в общем случае
"вычислительные ресурсы" и энергопотребление -- также синонимы.
Решение из Silicon Valley
То, о чем мы говорили, по сути -- очевидно.
И тем не менее кажется поразительным, что буквально "валяющаяся под ногами"
весьма интересная (в том числе и с точки зрения финансиста) проблема, требующая
решения, оставалась фактически без внимания так долго. Предлагавшиеся традиционные
способы (упомянутые выше библиотеки, реализующие базис GUI, средства быстрой разработки)
обладали рядом недостатков -- например, ограничивали производителя встраиваемого
вычислителя в выборе элементной базы, вынуждали его или держать в штате специалистов,
весьма далеких от основной специфики компании, или же тратить средства и время
на переподготовку имеющихся. Латентные для "продвинутого потребителя",
так любящего порассуждать о несправедливости ценообразования, факторы еще неприятнее.
GUI встраиваемых систем принципиально отличается от "беззатратного в тиражировании"
GUI универсального компьютера в силу того, что физическое устройство отображения
во втором случае уже присутствует в составе готового изделия (например, в комплекте
работоспособного ПК монитор, как правило, есть). Во встраиваемых же системах в
"комплект GUI" входит и само устройство отображения -- обычно небольшая
ЖК или люминесцентная панель. Такие устройства, грубо говоря, бывают двух классов
-- заказные и универсальные. Заказные панели способны отображать только то, что
в их "способности" заложено разработчиком (помните советские карманные
электронные игры типа "Ну погоди"?). Универсальные -- это маленькие
аналоги традиционных растровых устройств отображения. Естественно, что при использовании
любого из этих типов устройств разработчик чем-то да рискует. Заказные панели
незначительно увеличивают стоимость процесса разработки, но их цена очень сильно
зависит от тиража, а вот точно оценить тираж для еще не существующего устройства
могут разве что очень продвинутые гадалки. Универсальные панели требуют как дорогостоящего
и продолжительного этапа проектирования GUI, так и применения аналогов "традиционного"
проектного инструментария с вытекающими из этого последствиями, указанными выше.
Короче говоря, разработчик в любом случае вынужден в стоимость своего вычислителя
закладывать некоторую (но весьма ощутимую) компенсацию возможных рисков (только
из-за GUI), что без сомнения сказывается на конечной цене всего изделия, в котором
вычислитель является всего лишь одной из подсистем.
Как обычно, вопреки мрачности прогнозов о потенциале Силиконовой Долины, достойное
решение такой проблемы было найдено именно там. Естественно, теперь это защищенная
мощной патентной базой разработка, очевидность назначения и реализации которой
(равно как и востребованности на рынке) просто вызывают белую зависть.
Автор решения -- небольшая и сравнительно молодая приватная компания Amulet Technologies,
основанная в 1998 г., а суть решения -- дешевый аппаратно-программный интерпретатор
специального языка описания GUI с максимально упрощенным и сокращенным циклом
разработки. Впрочем, в этом случае краткость названия очень сильно влияет на его
точность...
Основная продукция Amulet -- специализированный микропроцессор, архитектура которого
адаптирована к требованиям разработчика GUI-подсистем. О получившем рыночное название
Easy GUI Browser≥ чипе известно немного -- это некая вычислительная машина фон-неймановской
архитектуры с уникальной системой команд и небольшим перечнем специфической периферии
-- настраиваемым контроллером универсальных тактильных ЖК-дисплеев (поддерживающим
монохромные растровые панели с разрешениями вплоть до стандартного VGA -- 640
480), таймером и подсистемой ввода/вывода, не налагающей практически никаких ограничений
на реализацию основного управляющего компьютера или группы компьютеров. С последними
Easy GUI "общается" посредством очень простого последовательного протокола
обмена (являющегося также интеллектуальной собственностью компании Amulet, но
с открытыми спецификациями и образцовыми реализациями).
Казалось бы, и что здесь такого? Можно подумать -- событие: всего лишь еще один
специализированный недорогой процессор оригинального назначения. И если бы перечень
продуктов Amulet завершался только этим чипом -- и вопрос, и утверждение были
бы справедливы, и этой статьи вообще не было бы. Но Amulet предлагает "кое-что
еще", и вот это "кое-что" во всех отношениях интересно.
Начнем со второстепенных деталей (почему они названы второстепенными, об этом
-- позже). Разработчик GUI по технологии Amulet по большому счету не пишет никаких
программ вообще. Он может рисовать (в прямом, а не в переносном смысле) GUI привычными
средствами... WYSIWYG-редактора html-страниц. То, что технология Amulet использует
именно "несовершенный" язык разметки html, а не "специальное нечто",
основанное на метаязыке XML, может показаться "немодным решением", но
и здесь в Amulet не прогадали -- незачем плодить сущности без необходимости, да
и армия Web-дизайнеров неисчислима (к слову, похоже, термин "embedded Web-дизайнер"
получает право на существование). Все, что, по сути, требуется от разработчика,
-- изучить тщательно "уложенные в нормы" html специфические "расширения"
от Amulet, обширный перечень готовых графических примитивов, и можно браться за
работу. Изготовленный по такому рецепту GUI является аналогом обычного Web-сайта,
при разработке которого использованы CGI-вызовы программ. Только вместо CGI в
Amulet применяется комбинация из "разделяемой" области памяти (между
чипом Easy GUI и управляющим объектом микроконтроллером) и последовательного протокола.
После создания функциональной модели GUI в виде "сайта" множество html-страниц
подвергается трансляции в программу на языке ╣HTML, который интерпретируется процессором
Easy GUI. Все -- на этом цикл разработки закончен!
Непосредственно управляющий объектом микроконтроллер "реагирует" только
на передаваемые с помощью протокола сообщения об указаниях пользователя и записывает/читает
в "разделяемой" посредством того же протокола памяти требуемые ячейки
-- все остальное (изменения в GUI, подтверждающие действия, формирование диаграмм
и схематических изображений регуляторов и т. д.) -- дело исключительно Easy GUI.
Учитывая хорошую инструментальную поддержку, обеспечиваемую Amulet, и элементарность
"проектного процесса" (рука не поднимается в данном случае использовать
этот термин без кавычек), картина получается впечатляющая -- по мнению экспертов
в области GUI для встраиваемых систем, суммарная экономия проектного времени достигает
немыслимой цифры -- 98% (!), причем не верить вполне уважаемым и особо не заинтересованным
в судьбе небольшой компании экспертам нет никаких оснований. Такая значительная
цифра обусловлена не столько элементарностью разработки собственно GUI, сколько
влиянием "прозрачности", понятности и простоты взаимодействия управляющего
контроллера с процессором Easy GUI. О косвенном росте надежности разрабатываемой
по такому принципу встраиваемой системы пока ничего не известно, но можно уверенно
говорить, что в самом худшем случае подобная технология "не повредит".
Вот почему прежде мы говорили о сугубо технических нюансах как о второстепенных
-- чудовищно щепетильным по отношению к техническим нюансам embedded-специалистам
совершенно безразличны и "модности" XML, и недостатки html. Их интересует
полноценная технология, позволяющая проектировать-отлаживать-производить.
И делать это эффективно.
Эволюция идеи
Забавно, что главная идея, воплощенная Amulet, по сути, с давних пор являлась
основой хорошо известной разработки под названием X Window. Под "главной"
мы подразумеваем, естественно, идею "вынесения" графической функциональности
на отдельный вычислитель. Почему это "хорошо" -- уже понятно, и это
мы не раз обсуждали прежде. Но, как говорится, кесарю -- кесарево... и в данном
случае "нюансы" сыграли вовсе не второстепенную роль. X Window -- одновременно
слишком низкоуровневый и сложный программный комплекс для того, чтобы претендовать
на роль эффективного GUI именно для встраиваемых систем. Даже специализированные
коммерческие embedded-реализации X Window и разнообразные построенные на "обрезках"
спецификаций их миниатюрные аналоги в силу низкого уровня и необходимости использовать
"настольные" принципы в проектировании GUI также остаются востребованными
в исключительно узких рыночных нишах. Появление Easy GUI как массового изделия
эти ниши еще больше сокращает. Факт, безусловно, малозначимый -- на рынке и так
осталась буквально пара компаний, специализирующихся на производстве основанных
на X Window встраиваемых GUI-подсистем.
А вот влияние идей Amulet если не на рынок embedded-систем в целом, то на умы
разработчиков можно опасно недооценить. Пока еще Easy GUI не очень совершенный
чип в одном -- в области взаимодействия с управляющими вычислителями. Но стоит
Amulet применить здесь что-либо более адекватное (например
-- CAN), и можно говорить о забавном "новом" подходе к формированию
распределенных управляющих систем, доводящем степень схожести идей с X Window
до предела -- "графический терминал-сервер" и множество программ-клиентов,
выполняющихся на разных компьютерах. Случится ли такая массовая "трансформация
сознания" разработчиков -- автор, естественно, предсказывать не в праве.
|
