Решаем, что лучше: плагины или приложения

Многие проекты ЛЕДАС по своей сути являются разработкой подключаемых модулей (плагинов) для программ САПР, начиная от мощных систем, таких как CATIA, и заканчивая более легкими решениями, такими как Rhino. Часто мы помогаем нашим клиентам решить, в какой форме лучше всего воплощать их идеи: в виде плагина или как отдельную программу.

В этом посте я хочу поделиться своими соображениями о том, почему и когда разработка плагинов является более уместным подходом по сравнению с созданием приложения с нуля. Я также расскажу о формах подключаемых модулей, которые можно использовать в тех или иных ситуациях. И обратите, пожалуйста, ваше внимание на наш опыт разработки плагинов для САПР.

Плюсы и минусы плагинов

Плагины создаются для решения определенных задач или добавления функций, отсутствующих в системах САПР. Хорошим примером является CAMWorks от HCL – расширенный плагин, который добавляет функции автоматизированного производства (CAM) в систему проектирования SolidWorks.

Сравнивая подключаемые модули и независимые приложения, мы пришли к выводу, что для программного обеспечения, используемого инженерами-разработчиками внутри компании с целью облегчения их повседневной работы, лучше подходят плагины. В некоторых случаях использование плагинов значительно снижает стоимость разработки. Готовые системы САПР работают с плагинами через свои API.

Недостаток плагинов в том, что они зависят от основного приложения: чтобы использовать плагин, необходимо приобрести лицензию, а также выполнить установку программного обеспечения, на базе которого написан плагин. При этом использование плагина будет ограничено количеством рабочих мест в целевой САПР.

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

Плюсы и минусы автономных приложений

Рассматривая разработку десктопного или веб-приложения, следует учитывать, что такому приложению потребуется геометрическое ядро, с помощью которого оно будет конструировать, представлять и тесселировать 3D объекты. (Больше узнать о геометрических ядрах вы можете на странице сайта ЛЕДАСа, посвященной 3D-моделированию.) Годовая стоимость лицензии на подписку на ядро обычно значительно выше, чем единовременный платеж за одну лицензию на САПР легкого или среднего класса, к которой будет подключаться плагин.

Еще одним источником затрат являются усилия по реализации 3D сцен: визуализация, манипулирование камерой (масштабирование, панорамирование, поворот) и манипулирование объектами (выделение, перемещение и т. д.). Плагину все эти функции главное приложение предоставляет через свой API; в случае автономных приложений они должны быть запрограммированы на низком уровне или с помощью лицензированного компонента визуализации.

Типы решений, основанных на использовании плагинов

API, предоставляемые системами САПР, обычно предполагается использовать для расширения и адаптации функций самой системы, а не для создания пользовательских процессов для решения конкретных задач. Кроме того, бывает не всегда легко создать специализированный плагин, который переопределяет пользовательский интерфейс хост-приложения и подменяет его рабочий поток своим собственным.

По нашему опыту, Rhino – отличный пример такой системы. Он позволяет скрыть большинство его панелей и панелей инструментов по умолчанию и заменить их нашими собственными панелями, которые можно легко создать с помощью WPF (Windows Presentation Foundation). Это дает нам почти такой же уровень контроля над пользовательским интерфейсом Rhino, как и в независимых WPF приложениях.

Пример окна и панели инструментов, добавленных в Rhino с помощью плагина

В других системах САПР использование такого подхода может оказаться проблематичным, поскольку в них могут использоваться устаревшие графические интерфейсы пользователя (вы слышали, например, о WxWidgets?) или ограниченный набор предопределенных элементов управления.

Однако, если у приложения есть внешний API, который может быть вызван из другого процесса, например через COM или WCF, мы можем создать пользовательский интерфейс плагина как внешнее приложение, которое взаимодействует с главной САПР-системой через API. Технически это уже не совсем плагин. Это позволяет нам создавать пользовательский интерфейс с использованием современных технологий, максимально хорошо соответствующих специфическим требованиям, и при этом полагаться на геометрическое ядро и возможности 3D сцены основного САПР-приложения. Этот подход довольно популярен, хотя и является несколько более сложным.

Как принять решение

Таким образом, критерием при выборе между плагином и отдельным приложением может служить оценка числа пользователей: если общая стоимость копий главной САПР не превышает стоимости пользовательского приложения (с лицензиями на геометрическое ядро и компоненты визуализации и затратами на реализацию 3D сцены), то плагин является более дешевым вариантом.

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

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

Заключение

В целом при разработке внутренних приложений в организациях, сотрудники которых уже используют определенную САПР, следует отдавать предпочтение плагинам. Это значительно снижает стоимость разработки, поскольку нет необходимости платить за лицензии основного программного обеспечения.