С большим интересом прочитал статью Константина Евченко "Выбор геометрического моделировщика" («САПР и Графика», №2 за 2002 г.).
Статья уже привлекательна тем, что является одной из редких попыток провести беспристрастный анализ программных продуктов. В отличие от большинства статей, рекламная часть в ней сведена к минимуму, если не считать неоднократного упоминания одной из компаний.
В текст статьи вкралась также одна неточность, связанная с тем, что системы ADEM и Cimatron отнесены к специализированным CAM системами. Смею утверждать, что ADEM и Cimatron – это интегрированные CAD/CAM системы с гибридными объемными моделировщиками, поддерживающими и поверхностное, и твердотельное моделирование.
Особое внимание привлекли тесты для объемного моделирования.
Идея собрать систему тестов, которая бы помогла выбрать САПР, сама по себе неплоха. Но есть, к сожалению, объективные причины, которые не позволяют воспользоваться данным механизмом. Хочу поделиться своими соображениями на этот счет.
Любая компания-разработчик имеет в своем арсенале сотни и тысячи тестов для контроля качества своего программного продукта. И следует сказать, что этот капитал является одним из самых главных ноу-хау компании.
Тестовые задачи делятся на две группы – решенные и проблемные. Последние определяют потенциальные направления разработок и держатся в строжайшем секрете.
Еще более важной информацией являются приоритеты в списке проблемных задач, которые отражают состояние ниши рынка данного программного продукта. Приоритеты, в первую очередь, связаны с текущими и потенциальными контрактами. От прохождения этих тестов нередко напрямую зависит финансовое положение компании.
Хороший тест - это отфильтрованная часть практической задачи. Но это далеко не всегда пример на кубике. И вот почему. Если взять хорошо развитый моделировщик верхнего или даже среднего уровня, то его интеллект можно условно разделить на две части:
- работа с аналитическими объектами - 1 %
- работа со сплайновыми объектами -99 %
Аналитические - объекты, описываемые системой поверхностей: сфера, тор, цилиндр, конус, эллипсоид, плоскость.
Кстати, все (кроме 10) примеры, приведенные в статье, основаны именно на таких объектах. В частности, пример 12 - построение поверхности по плоским профилям: квадрату, окружности и треугольнику. Пример 13 - чистая аналитика - цилиндры, сферы и торы. В примере 15 говорится о пространственной линии, а иллюстрируется тест на плоской дуге.
Если производить сравнение моделировщиков по решению задач с аналитическими объектами, то практически все они будут работать примерно одинаково, ну, может быть, за исключением особо "выдающихся", которые не умеют делать скругления внутреннего угла или строить скругление переменного радиуса.
Надежда, что для кого-то хватит аналитических поверхностей, явно несбыточна. Обратите внимание на то, что результатом большинства приведенных тестов является построение неаналитических поверхностей (1,2,3,4,5,7,8,10,11,12,15,17).
Это означает, что любой последующий шаг работы с системой может потребовать сплайновой математики. И математика эта должна быть уже не просто на уровне построения сплайновых поверхностей по аналитическим, а на уровне сложного взаимодействия сплайновых объектов друг с другом. 
Рис. 1. Для повторения теста с неаналитическими объектами одного описания и иллюстраций недостаточно
О сплайновой математике следует сказать, что практически невозможно описать тест в текстовом виде так, чтобы его смогли точно повторить другие. Для повторения теста нужны конкретные тела и поверхности с конкретными данными (см. рис 1). Это первое, что ограничивает возможности создания универсальной системы тестов для современных моделировщиков. Иными словами, для точного повторения теста одних фразеологических данных и иллюстраций не достаточно.
Но не только сплайны составляют основную проблему для разработчиков CAD систем. Очень много вопросов возникает из-за негладкости объектов.
Следует обратить внимание на тот факт, что ряд функций даже в самых развитых системах, применимы только к одной поверхности или к группе гладко состыкованных поверхностей. Взгляните на пример 16. Вряд ли кто в жизни будет строить карман с нормальными стенками на яйце. Скорее всего, карман окажется в том месте, где негладко сходятся конические и цилиндрические поверхности. А в общем-то, одной фантазии не хватит, чтобы придумать необходимый минимум тестов для этой функции. Это сделает только практический опыт. Не менее распространенная и сложная задача - автоматическое построение поверхности разъема. Могу с уверенностью сказать, что здесь найти реальный пример, который не сделает никто, так же просто, как встретить свердловчанина в Екатеринбурге. И что тогда иллюстрирует тест на яйце ?
Следует также отметить, что оценка системы по критерию тест пройден/не пройден - далеко не всегда соответствует практический ценности системы.
Посмотрите на пример 12. Возможно, кому-то и понравится приведенное решение задачи, но большинству - нет. В реальной практике очень важно избежать несостыковки ребер, которая приведена в иллюстрации. Подобные результаты обычно считаются нетехнологичными или нерациональными.
Решение теста 11 - это лишь одно частное решение задачи. На практике редко применяют абстрактные переходы. Обычно требуется не просто получить произвольную поверхность, а ту, что удовлетворяет конкретному критерию (см. рис 2). 
Рис 2. Множество вариантов решения задачи: постоянный радиус, минимум кривизны, постоянный модуль радиуса, постоянная площадь сечения и т.д.
Известно, что один и тот же результат может быть достигнут различными путями. Практически все предложенные примеры решаются методами твердотельного моделирования. Но это отнюдь не означает, что этими методами удастся воспользоваться в контексте конкретной реальной задачи. Посмотрим на пример 3. Для многих систем - это задача в одно действие. Но почему-то постановщик теста указал, что верхняя кромка поверхности должна быть плоской, что так же не составляет труда сделать, вырезав нужную поверхность из тела. Для чего же приведено данное условие? Скорее всего, эта задача имеет непростое решение в рамках некоторой макрозадачи. Иными словами, прохождение теста не всегда означает успех применения данной функции в реальной жизни. Кстати, минимум количества нажатий на кнопки или скорость выполнения теста может свидетельствовать не об интеллекте системы, а скорее, наоборот - о том, что разработчики не видят большинства нюансов, которые преподносит жизнь и применяют неуниверсальные алгоритмы.
Работая над тестами для объемного моделирования, не следует также забывать важную истину: моделирование является основой для решения других задач. На результате моделирования жизнь не заканчивается, а, как правило, только начинается. Получение правильной картинки совсем не означает, что качество модели достаточно для ее изготовления. И если "накопление погрешности может помешать сшить ее в твердое тело", то к каким же серьезным проблемам могут привести недостатки моделирования в вопросах подготовки производства ?!
Ну а теперь о главном! На самом деле невозможно говорить о проведении теста моделировщика, так как всегда тестирование проходит система "пользователь - программный продукт". Может ли начинающий исполнитель по самоучителю сыграть лучше на скрипке Страдивари, чем на инструменте, купленном в магазине «Аккорд»? Думаю, что результат будет прямо противоположным. Начинающий яхтсмен скорее потопит яхту экстра-класса, чем надувную лодку.
Более того, начинающий специалист не всегда может правильно оценить результат теста. На рис. 3 приведен один из вариантов разъема стержневой прессформы для вкладыша. Решение по поверхности разъема и стержням получено автоматически. При этом, система позволяет получать различные результаты при различных исходных данных . Я очень сомневаюсь, что рациональность данного решения будет правильно оценена неопытным сотрудником. 
Рис 3. О чем говорит данный результат теста функции автоматического определения разъемов прессформы ?
Если мы хотим тестировать сообразительность начинающих пользователей, то, конечно, задача пересечения двух усеченных пятиугольных пирамид для построения правильного додекаэдра может считаться сложной, важной и полезной. Но если мы говорим о проверке качества профессиональных продуктов, предназначенных для решения реальных задач, то я боюсь, что подобная система тестов только запутает непросвещенного пользователя.
Итак, я привел три основные причины, которые являются серьезным препятствием для создания универсальной системы тестов по выбору моделировщика:
- фразеологического и иллюстративного описания недостаточно для повторения большинства тестов на сплайновых и составных объектах
- сложно учесть нюансы при проведении теста вне рамок макрозадачи
- проведения тестирования неопытным пользователем вряд ли можно считать тестированием системы, а опытный пользователь уже давно сделал свой выбор.
Все сказанное выше совсем не означает, что надо оставить тему тестирования систем. Скорее наоборот, проблема проведения экспериментов - одна из самых достойных для обсуждения на страницах главного журнала САПР нашей страны. Поэтому хочется выразить глубокую благодарность Константину Евченко, Владимиру Власову и другим соавторам представленной методики за джина, которого они выпустили из бутылки.