Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель: ООО НТЦ «АПМ»

ИНН 5018019971 ОГРН 1035003357366

Рекламодатель:
ООО «С3Д Лабс»

ИНН 7715938849 ОГРН 1127747049209

12 - 2015

Может ли nanoCAD заменить западные САПР-решения? Давайте искать ответ…

Денис Ожигин

При внедрении нашей САПР­платформы мы часто сталкиваемся с тем, что мало кто в нашей стране может адекватно оценить функционал такого сложного и многогранного инструмента, как САПР, полноценно сравнить конкурирующие решения и дать непредвзятую оценку. Чаще всего такую работу поручают местному «САПР­гуру» — специалисту­«фанату», мнение которого может быть (и скорее всего будет) предвзятым, так как он любит решение, используемое им в данный момент. В результате получаем список «вкусных», но малоиспользуемых функций, которые «вы должны сделать — иначе никакого внедрения!», а тема импортозамещения плавно затухает. В ответ мы задумались об инструменте, который позволит сделать независимую оценку, реализовали его и теперь готовы поделиться им с вами.

Введение

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

  • всё полностью автоматизировано — нужно только включить ведение журнала;
  • всё абсолютно конфиденциально — в журнал логов включается только информация о вызываемых командах, а не о самом проекте;
  • сбор статистики абсолютно не мешает каждодневной работе пользователя — запись в журнал — достаточно легкая операция.

Самое главное — такой сбор статистики позволяет провести максимально полный анализ: вы можете собирать журналы хоть в течение целого года, а программа будет аккуратно коллекционировать в папочке вызовы команд. Также вы можете проводить анализ, разбив пользователей по группам, — просто укажите разные папки для сбора статистики. А журналы затем покажут, какие команды платформы использовались, применялись ли какие­нибудь приложения или дополнительные разработки, каков уровень использования платформы и приложений (частота вызова команд). Словом, беспристрастная статистика и никакого субъективизма.

Возникает вопрос, а как включить такой журнал? Тут всё просто: в командной строке вводим команду Параметры (или OPTIONS для английской версии). Далее идем на закладку Открытие/Сохранение (или Open and save) и взводим опцию Вести файл журнала (или Maintain a log file) — рис. 1. Как результат выполнения этой команды в системную папку, задаваемую переменной LOGFILEPATH, будет сохраняться информация из командной строки (журнал команд).

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

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

В принципе, все это настраивается еще через три системные переменные: LOGFILEMODE (включить/отключить режим ведения журнала), LOGFILEPATH (путь до папки ведения журналов) и LOGFILENAME (путь до текущего журнала команд). У вас нет таких команд? Скорее всего, вы пользуетесь САПР, которая не позволяет вести журнал вызываемых команд, и здесь требуется не импортозамещение, а переход с конкурирующих решений — это чуть другая история...

Итак, включили журнал ведения логов, собрали логи в папку — что дальше?

Предварительная обработка данных

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

Если заглянуть внутрь, то мы увидим всё, что писалось в командную строчку: вызовы команд (то, что нас интересует), системные сообщения, ответы пользователя, значения переменных, сообщения об ошибках, предупреждения и т.д. Все это надо теперь обработать и составить список вызываемых команд с информацией о том, как часто вызывали каждую из них. Для этого мы написали простую утилиту (http://bit.ly/1SLo7vY)на языке AutoIt, которая применяется к log­файлам в указанной папке, последовательно их обрабатывает и формирует массив команд с подсчетом частоты их вызова (рис. 3).

Рис. 2. Типичная папка с журналами команд —

Рис. 2. Типичная папка с журналами команд —
на каждый файл отдельный журнал

Рис. 3. Утилита StatCAD, которая позволяет обработать журналы команд и сформировать список использованных команд

Рис. 3. Утилита StatCAD, которая позволяет обработать журналы команд и сформировать список использованных команд

Работа с утилитой StatCAD очень проста: достаточно указать папку с логами, нажать на кнопку Анализ, дождаться окончания работы и, нажав на кнопку Показать статистику, получить список в отдельном окне. Данные из этого окна можно скопировать в Excel или текстовый формат — как вам удобнее. А дальше начинается творческая работа.

Обработка полученной статистики

Во­первых, мы должны в полученном списке выделить команды САПР­платформы, а значит необходим список штатных команд платформы, с которой сравниваем. Сейчас мы накопили порядка 2400 команд, системных переменных и алиасов­сокращений (как на русском, так и на английском языке), с которыми проводим сравнение — простое пересечение таблиц в Access позволяет одним щелчком мыши получить сходные и отличающиеся команды. Сложнее всего с отличающимися командами — их приходится анализировать вручную, отделяя синтаксические ошибки от команд приложений, команд, написанных пользователями и т.п. Зачастую результат удивляет (рис. 4) — статистика может показать, что доля платформы существенно превышает долю приложений.

Кроме того, мы можем сравнить список распознанных команд САПР­платформы со списком реализованных команд платформы nanoCAD Plus — это тоже пересечение двух таблиц в Access. В результате мы получим список команд, реализованных в режиме «один к одному» (полное совпадение).

Рис. 4. Предварительный список команд может содержать как вызовы приложений, так и синтаксические ошибки

Рис. 4. Предварительный список команд может содержать как вызовы приложений, так и синтаксические ошибки

Рис. 5. Диаграмма, наглядно сравнивающая список команд nanoCAD Plus со списком команд западной САПР-платформы, используемой у одного из заказчиков

Рис. 5. Диаграмма, наглядно сравнивающая список команд nanoCAD Plus со списком команд западной САПР-платформы, используемой у одного из заказчиков

Рис. 6. А если сравнивать команды по частоте вызова,

Рис. 6. А если сравнивать команды по частоте вызова,
картина будет еще более убедительной

Результаты анализа

И наконец, список оставшихся команд разбивается на три части:

  1. ?Реализованный функционал, то есть команды, которые не проходят через командную строку nanoCAD Plus, но реализованы через интерфейс программы, и их отсутствие пользователь на практике не заметит. Например, команда PDFATTACH (вставка PDF­подложек) на данный момент не зарегистрирована в списке команд nanoCAD и, тем не менее, доступна из меню Вставка/Подложки…
  2. ?Альтернативный функционал, то есть команды, которые в силу особенностей разработки отличаются от аналогичных команд других САПР, но позволяют пользователю решать поставленные задачи аналогично или даже с более высокой производительностью. Например, работа с таблицами в среде nanoCAD Plus 7.0 заточена под российские стандарты оформления плюс операции сбора данных с текущего *.dwg­чертежа — достаточно уникальная функция, объединяющая несколько инструментов в один.
  3. ?Нереализованный функционал, то есть команды, которые сейчас не работают в среде nanoCAD Plus 7.0 и, увы, нет никакой альтернативы для их замены. Часть этих функций находится в разработке (например, Подшивки, Инструментальные палитры), часть — требует анализа и дополнительного согласования по реализации, а часть — явно необязательна к реализации (например, Вызов веб­сайта 360).

Третья часть с точки зрения анализа — самая сложная: требуется проанализировать каждую команду, уточнить, что она делает, какая альтернатива возможна в платформе nanoCAD Plus (а может быть, она уже и реализована), и если команда отсутствует, то оценить, насколько отсутствующая функция необходима в работе организации. Это ручной аналитический труд, но в результате вы будете вознаграждены отличной говорящей диаграммой (рис. 5).

Но и это еще не всё — помните, что мы не просто сформировали список вызываемых команд, но и собрали статистику по частоте их вызова? И правда, одно дело — ответ на вопрос «реализована команда или нет?» и совершенно другое — «используется ли вызванная команда?». И тут тоже можно получить говорящие результаты (рис. 6): доля нереализованного в nanoCAD функционала может упасть до 1­3%! Это означает, что в подавляющем большинстве случаев пользователи не заметят разницы возможностей между nanoCAD и западными решениями.

Вместо заключения

Признаюсь, когда я впервые получил подобные результаты, у меня самого был шок. Получается, что платформа nanoCAD может достаточно свободно замещать популярные западные решения в функциональном плане: в 97­99% случаев пользователи получат альтернативный инструмент для работы. На сегодня я провел подобный анализ в пяти организациях: соотношения команд примерно одинаковы, и я перестаю удивляться.

Тем не менее думаю, что результаты анализа могут сильно различаться от одной организации к другой. Именно поэтому я хочу поделиться всеми материалами — попробуйте провести анализ на своем предприятии, и давайте совместно ответим на вопрос «Возможно ли импортозамещение на nanoCAD Plus?». Что у меня есть:

  1. утилита StatCAD 3.01 (http://bit.ly/1SLo7vY), которая обрабатывает log­файлы и собирает статистику по командам используемой вами САПР­платформы. Делюсь с вами как исполняемым модулем, так и AutoIt­скриптом (исходный код);
  2. Excel­таблица со списком известных на данный момент команд (http://bit.ly/1XeaVAZ), системных переменных и сокращений как платформы nanoCAD, так и одной из известных западных САПР­платформ. Кроме того, таблица содержит список найденных отличающихся команд с анализом на тему того, к какой группе команд относится каждая из них (альтернатива, реализовано, не реализовано);
  3. пример папки с log­файлами (http://bit.ly/1Qy9QoH), на котором вы можете «прогнать» утилиту StatCAD 3.01. Лучше, конечно, положить сюда ваши собранные log­файлы;
  4. Excel­ и Access­документ, анализирующий таблицы (http://bit.ly/1SLoHtA), — просто поместите в файл CLIENT_CMD.xlsx результат работы StatCAD 3.01 и открывайте в Access таблицы 02ACAD_CROSS, 02ACAD_NOTFOUND, 03ACAD­NCAD_CROSS, 04ACAD­NCAD_NOCROSS — думаю, что названия таблиц говорят сами за себя.

Если у вас не получается провести анализ собранной статистики своими силами, буду рад получить ваши log­файлы или Excel­таблицы со списком используемых вами команд (заполненный CLIENT_CMD.xlsx из приложенных архивов). В этом случае я смогу провести анализ самостоятельно и использовать полученные результаты для развития платформы nanoCAD. Поверьте, это будет очень полезная для нас информация — на основании этих данных мы развиваем продукт, а вы получаете всё более удобный инструмент.

Дисклеймер

Данный анализ демонстрирует принципиальную возможность или невозможность замены одного САПР­решения другим, но не гарантирует результата. Любое внедрение, кроме приведенного в статье технического аспекта, связано с рядом других технических, организационных, психологических и прочих моментов. Именно поэтому мы рекомендуем работу по импортозамещению проводить совместно с авторизованными дилерами ЗАО «Нанософт».

САПР и графика 12`2015

Регистрация | Войти

Мы в телеграм:

Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557