ПО

Индустрия встраиваемого ПО быстро развивается. Движущей силой этого процесса являются два фактора: стремление сократить время выхода продукта на рынок и возможность применения уже готовых коммерческих программных компонентов.

Исторически сложилось так, что первоначально циклы разработки длились не месяцы, а годы. Это было обусловлено тем, что компании-производители оборудования (OEM-производители) выполняли разработку всех элементов продукта начиная с самых основ (аппаратное обеспечение, базы данных, ОС, графический интерфейс, IP-стеки и т. д.) Подобная практика становилась все менее эффективной и требовала больших временных и финансовых затрат. Потребность OEM-производителей в более качественных программных решениях вызвала значительный рост рынка встраиваемого ПО за последнее десятилетие. Сегодня при создании большого числа программных решений они используют готовые коммерческие программные компоненты, включая ОСРВ (Linux, QNX, VxWorks, WinCE), IP-стеки (Wind(r)NET), базы данных (Birdstep RDM, Encirq 3e) и т. д. В результате компаниям-разработчикам продуктов нужно лишь интегрировать те или иные базовые программные компоненты и сконцентрировать усилия на особых функциональных возможностях продукта, отличающих его от конкурентов и создающих преимущество для пользователей.

Применение готовых коммерческих программных компонентов обусловлено желанием сократить длительность цикла разработки и снизить сопутствующие издержки. Поставщики готовых коммерческих программных компонентов обычно и позиционируют свои продукты с точки зрения возможности сократить время вывода продукта на рынок. Хотя показатель времени вывода на рынок является ключевым при оценке капитальных затрат, на рынке встраиваемого ПО все большую роль начинает играть другой фактор: насколько программный компонент увеличивает доход и прибыль. Кроме того, нужно учитывать, что клиенты из числа OEM-производителей знают о наличии разных готовых программных решений и возможности быстро их интегрировать в состав своего продукта. Например, нередко клиенты даже настаивают на выборе определенной ОСРВ. ПО легко адаптируется, и конечные клиенты заинтересованы в установлении партнерских отношений с теми поставщиками, кто хочет работать с ними в тесном сотрудничестве и может своевременно и экономически эффективно реализовать их специфические требования. Ожидается, что продукт быстро выйдет на рынок. Однако при этом важно, чтобы поставщики наряду с удовлетворением индивидуальных требований клиента не понесли дополнительные неоправданные расходы на разработку и исследования. Это обстоятельство является важным соображением, поскольку оно непосредственно влияет на бизнес-модель ОЕМ-производителя и на увеличение его доходов.

Четыре уровня разработки графических пользовательских интерфейсов

Готовые коммерческие компоненты, такие, как операционные системы, в значительной степени были исследованы при проведении анализа бизнес-эффективности предлагаемых решений, однако при этом программные инструменты для создания графических пользовательских интерфейсов (GUI) в основном игнорировались. Не уменьшая важности фактора быстрого вывода продукта на рынок, можно сказать, что конкурентоспособность OEM-производителей может в значительной степени определяться архитектурой предлагаемых графических решений.

Для лучшего понимания этого факта нам следует сначала рассмотреть различные категории графических пользовательских интерфейсов в порядке их эволюции.

Существует четыре основных уровня разработки GUI-решений.

Решения собственной разработки

Решения собственной разработки создаются с нуля. Например, для того чтобы нарисовать спидометр, программист компании должен написать код программы, обеспечивающий прорисовку шкалы, каждой градуировочной метки, всех текстовых блоков, фоновую и цветовую заливку, а также реализующий позиционирование, движение и функционирование всех этих элементов дизайна спидометра. Чтобы показать движение стрелки, программисту надо стереть и нарисовать ее на новом месте шкалы спидометра. Для успешного выполнения этой работы требуются значительные усилия и опыт.

Библиотеки графических пользовательских интерфейсов

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

Генераторы программного кода

Большинство современных передовых графических пакетов принадлежат к этой категории. Генераторы программного кода включают не только GUI-библиотеки, упомянутые выше, но также и компонент, который генерирует программный код графического пользовательского интерфейса. Этот код, в свою очередь, использует библиотеку, поставляемую вместе с компонентом. При рисовании спидометра соответствующий объект, имеющийся в библиотеке, располагается на подложке программного средства; атрибуты объекта (цвет, шкала и т. п.) определяются не программным образом, а устанавливаются с использованием ниспадающего меню. По завершении построения экранного макета генерируются программный код графического пользовательского интерфейса и файлы ресурсов (конфигурации), которые компилируются вместе с библиотекой в бинарный код OEM-приложения. Генераторы кода облегчают бремя разработки программного кода, но OEM-производители тем не менее несут ответственность за то, что они делают, за отладку, тестирование и обслуживание своего сделанного на заказ GUI-приложения.

Графические машины

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

Изменение времени вывода продукта на рынок и стоимости разработки при последовательном переходе от первой к четвертой категории GUI имеет линейный характер; разработка собственных решений требует наибольших усилий, а использование графической машины-наименьших.

Влияние GUI-решений на архитектуру продукта

Выбор готового программного решения на основании лишь минимизации времени вывода продукта на рынок может иметь в перспективе существенные последствия для некоторых OEM-производителей. Наряду со временем вывода продукта на рынок им следует учитывать то, как предлагаемое готовое GUI-решение влияет на архитектуру, ликвидность и рентабельность выпускаемого ими конечного продукта.

Готовые коммерческие библиотеки графического интерфейса пользователя и решения, основанные на применении генератора программного кода, отличаются друг от друга временем вывода продукта на рынок, но их влияние на архитектуру конечного продукта OEM-производителя и, следовательно, на ведение бизнеса сходно.

На рис. 1 показаны процедура разработки и конечная архитектура продукта, соответствующие случаям использования готовой коммерческой GUI-библиотеки и генератора программного кода. Различие между этими двумя готовыми GUI-решениями проявляется на этапе разработки. В отличие от использования GUI-библиотеки средство генерирования кода генерирует исходный код GUI (GUI SRC) и файлы ресурсов (файлы конфигурации, RES FLS). В обоих случаях исходный код GUI (сгенерированный или разработанный с нуля) компилируется в двоичный код приложения и при использовании генератора программного кода компонуется с графическими библиотеками (XXX GRPH LIBS) и файлами ресурсов (RES FLS). Архитектура полученного конечного продукта обладает двумя важными характеристиками:

Рис. 1. Процесс разработки и архитектура конечного продукта в случае использования

готовой GUI-библиотеки или генератора программного кода  

  

1) GUI и программный код приложения скомбинированы в единое целое;

2) графические библиотеки и файлы ресурса (генерируемые лишь при использовании генератора программного кода) также компонуются в единый двоичный исполняемый код.

Эти две характеристики существенным образом влияют на бизнес-модель OEM-производителя, когда ему требуется изменить конечный продукт в целях обеспечения его соответствия требованиям конечного заказчика. Например, на рынке автомобильных информационно-развлекательных средств OEM-производители первого эшелона продают свои продукты множеству конечных клиентов (например, Toyota, BMW, Daimler Chrysler, Honda, Ford и т. п.). На этом рынке нередко каждый конечный клиент создает собственный интерфейс пользователя, еще и каждый раз другой для различных модификаций одного и того же продукта.

Использование подобных архитектур заставляет OEM-производителя связывать программный код приложения и GUI с файлами ресурса (конфигурации) и графическими библиотеками. Как результат, OEM-производитель вынужден иметь высокооплачиваемых инженеров для изменения или регенерирования кода, выполнения его компилирования или компоновки, а также тестирования нового программного кода GUI для каждого конечного клиента и при необходимости для каждой модификации его продукта. Все это приводит к дополнительным расходам на разработку, тестирование и обслуживание.

Рассмотрим теперь процедуру разработки и архитектуру конечного продукта, созданного с использованием двоичного GUI-решения. Это решение обладает теми же возможностями, что и решение, основанное на использовании генератора программного кода. В данном случае не требуется разрабатывать специальный программный GUI-код, и двоичная графическая машина предоставляет в соответствующем формате все функции, которые необходимы в конечном решении. OEM-производителю надо лишь сконфигурировать свойства объектов с использованием поставляемого средства разработки. Графическая машина отобразит GUI-объекты в соответствии с конфигурацией, заданной в файлах ресурса (см. рис. 2).

Рис. 2. Процесс разработки и архитектура конечного продукта в случае использования

готовой коммерческой графической машины      

В отличие от ситуации, изображенной на рис. 1, файлы ресурса (RES FLS) не входят в состав кода приложения или графической машины. Они представляют собой отдельные файлы, которые хранятся в целевой системе. Кроме того, графические библиотеки не поставляются вместе с OEM-приложением и не компилируются в его код. Вместо этого пользователь настраивает коммуникационный API (XXX COMM API) с целью обеспечения взаимодействия между приложением, графической машиной и GUI.

В контексте рассмотренного выше примера для автомобильного OEM-производителя можно указать на два существенных с технической точки зрения различия:

- GUI OEM-приложения не входит в состав его двоичного кода;

- файлы ресурсов не входят в состав кода OEM-приложения или готовой коммерческой графической машины GUI.

Подобное разделение GUI и основного приложения имеет следующие преимущества:

- OEM-производители могут легко изменять интерфейс пользователя и обеспечивать его соответствие требованиям клиентов без проведения каких-либо изменений в коде приложения. Поскольку изменение интерфейса пользователя приводит лишь к изменениям в файлах ресурса, никакой разработки нового программного кода, его компилирования и компоновки не требуется. OEM-производитель лишь реконфигурирует файлы ресурсов и размещает их в отведенном месте флэш-памяти. Встроенная графическая машина отобразит интерфейс пользователя в соответствии с представленными новыми файлами ресурсов;

- модификация GUI не только требует меньших временных затрат, но также может быть выполнена в процессе работы целевой системы. Поскольку изменения предполагают лишь реконфигурацию файлов ресурса, OEM-производители могут быстро разрабатывать соответствующий прототип GUI в присутствии клиентов и легко модифицировать его;

- так как нет необходимости в разработке нового программного кода, OEM-производители могут использовать более дешевые кадровые ресурсы (инженеров-эксплуатационников, графических дизайнеров) для конфигурации интерфейса;

- повышается надежность графической машины, благодаря тому что она тестируется множеством пользователей;

- при использовании решения, основанного на графической машине, OEM-производитель может более быстро и экономически более эффективно перейти на другую платформу (например, Linux, QNX, VxWorks, и т. п.). Обеспечение поддержки множества платформ (RTOS/CPU/оконная система) является тривиальной задачей, поскольку продавец готового ПО поставляет свою многоплатформенную графическую машину в двоичном формате, а файлы ресурсов не зависят от платформы.

Заключение

Использование в ОЕМ-приложениях графических машин (вроде тех, что предлагает, например, компания Tilcon Software) не только ускоряет получение дохода от вложенных средств и снижает расходы на проведение разработок и исследований, но также предоставляет OEM-производителям возможность увеличить свою прибыль. Вместо того чтобы рассматривать договор с каждым клиентом как отдельное обязательство на проведение проектно-конструкторских работ, OEM-производители могут теперь поставлять на рынок гибкое платформенное решение, которое легко, быстро и экономически эффективно настраивается под любые потребности потенциальных пользователей.