Программирование под САПР. Важные моменты

Если придется программировать под САПР, то важно предусмотреть несколько важных моментов:

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

Для программирования под САПР подходят несколько языков и все они имеют свои особенности.

  1. LISP — интерпретированный код, его можно хранить на локальной машине или на сервере. Но если сервер в вашей компании не отличается стабильной работой, то лучше не использовать его в качестве хранилища. Код LISP можно компилировать в форматы FAS и VLX и такие варианты будут работать гораздо быстрее, чем некомпилированный код.

Все вместе можно откомпилировать либо в один большой файл, или в несколько файлов. В чем отличие? Если все закомпилить в один файл, то, соответственно, периодически перекомпиливать придется только его, а в случае наличия библиотеки файлов — собирать придется сначала конкретный библиотечный файл, а потом закомпиливать решение. Это зависит от ваших предпочтений. На мой взгляд, работа со сборкой (библиотекой файлов) предпочтительней. Но в любом случае, некомпилированные варианты файлов всегда нужно иметь, т.к. отладка доступна только в исходниках.

  1. ARX (C++)

Код на ARX быстро работает и его можно загружать с сервера или выгрузить из AutoCAD. Но в этом случае нужно отлично знать С++ и AutoCAD. Для компиляции кода нужно использовать только Visual Studio. С другими компиляторами совместимости нет.

  1. .NET

.NET — сборки отлично работают, но стабильно загружаются только локально. С сервера, в принципе, тоже можно загрузить, но придется сильно шаманить с реестром Windows. Выгрузить .NET приложение, загруженное в AutoCAD невозможно. Удобно, что писать эти приложения можно на любых .NET-языках (VB.NET, C#, F#и других). Причем, члены команды разработчиков могут писать код на разных языках, а потом собрать все в одно решение (Solution).

Доступ к реализованным библиотекам можно предоставлять тремя способами.

  1. Через организованное меню. В этом случае формат предоставления определяется версией ПО. В принципе можно предоставлять доступ к написанным библиотекам через корпоративное меню AutoCAD, но это не очень удобно, т.к. возможно будет тормозить. Оптимальный вариант — организовать локальные копии меню. В этом случае при загрузке меню проверяет дату меню в серверном каталоге и при необходимости синхронизирует локальную копию.
  2. Через список команд. В этом случае нужно продумать имена команд. Они должны быть короткие и запоминающиеся и не должны дублировать штатные команды AutoCAD. Нужно обязательно предоставлять список команд пользователям.
  3. Через справку. Справка необходима. Ее можно организовать, например, в chm-формате и вызывать с сервера.

Загружать написанные приложения можно через Upload или реестр. Во втором случае придется прописывать приложение в защищенных ветках реестра, что весьма неудобно.

Хорошо, если acaddoc.lsp, acad.lsp нормально грузятся с сервера, но лучше организовать загрузку через меню.

  • dvb можно загрузить с сервера или с локальной машины
  • lsp, fas, vls лучше держать в корпоративной сети, если она устойчива
  • arx можно подгрузить и выгрузить с локальной машины
  • .NET можно загрузить только локально.

Как обновлять написанные под САПР приложения?

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

Весь код, написанный под САПР должен быть задокументирован. Если использовать при написании ПО любой из языков .NET, то можно использовать самодокументирующийся код, а в LISP такого нет и придется писать справку для разработки. Документирование сборки позволит осуществить контроль отдела САПР.

Еще важно сразу определить место хранения исходников и текстов, писать справку с использованием понятной широкому кругу читателей терминологии, и конечно же, придерживаться правил именования функций, процедур и файлов, принятых в компании.