CADmaster

Быстрый просмотр файлов

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

За просмотр файлов отвечают специальные программы, чаще всего называемые вьюерами (от англ. viewer). Учитывая большое разнообразие форматов файлов, вам наверняка захочется иметь вьюер, поддерживающий как можно большее их количество. Но у такого выбора есть недостатки:

• мультиформатные вьюеры — это коммерческие программные продукты, цена на которые достигает сотен долларов за одно рабочее место;
• как показывает опыт, наиболее качественно работают средства просмотра, поставляемые или самим разработчиком формата файла, или компанией, разрабатывающей средства просмотра на лицензионных библиотеках. К слову сказать, для многих распространенных, но закрытых форматов таких библиотек не существует. Например, авторам статьи не удалось найти качественных средств просмотра документов… Microsoft Office, написанных сторонними производителями. Даже весьма популярным платным средствам просмотра откровенно «сносит крышу» на документах, содержащих сложную разметку, встроенную графику или русский текст.

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

TDMS поддерживает технологию, позволяющую подключить произвольное количество программ, подгружаемых в область окна просмотра. Аналогичная технология используется в Microsoft Internet Explorer, где просмотр файлов обеспечивается программными компонентами, поддерживающими технологию ActiveX. Универсальное окно просмотра TDMS работает в качестве внешней оболочки для зарегистрированных в операционной системе компонент. При установке TDMS на рабочее место пользователя автоматически настраиваются наиболее популярные программы, такие как Microsoft Internet Explorer, Windows Media Player, Adobe Acrobat Reader, Autodesk DWF Viewer, Autodesk Inventor Viewer и др.

Кроме того, TDMS осуществляет настройку программы TDMS Viewer, обеспечивающей просмотр основных растровых форматов, форматов файлов приложений серии Raster Arts производства компании CSoft Development, форматов DWG, DXF и PDF. Но все-таки основное назначение TDMS Viewer — обеспечение просмотра файлов в защищенном режиме, без прямого к ним доступа.

Защищенный просмотр

Открытый на просмотр стандартными средствами редактирования (такими как AutoCAD) файл может быть сохранен на локальном диске или переносном устройстве хранения данных. И хотя правильно настроенные права доступа не позволят злоумышленнику скопировать целый проект, остается возможность хищения и использования в корыстных целях отдельных важных документов.

Для решения этой проблемы в TDMS используется технология, исключающая прямое обращение к запоминающим устройствам при просмотре графических файлов. Входящая в комплект поставки TDMS программа просмотра TDMS Viewer — это ActiveX-компонента, обеспечивающая просмотр файлов в защищенном режиме. Суть технологии защищенного просмотра заключается в том, что файлы передаются с сервера базы данных или файлового сервера в виде потока данных и формируются для просмотра только в оперативной памяти локального компьютера. Использование защищенного просмотра предотвращает попадание файлов на постоянные запоминающие устройства.

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

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

Опытные пользователи наверняка успели подметить, что TDMS Viewer не обеспечивает просмотра файлов многих распространенных форматов, например, тех же приложений Microsoft Office. Как обеспечить защищенный просмотр файлов, формат которых не поддерживается TDMS Viewer?

Чтобы ответить на этот вопрос, рассмотрим следующую технологию.

Универсальные форматы данных

Зачем нужен универсальный формат?

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

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

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

Широкая распространенность файлов универсального формата должна подтверждаться их использованием за пределами мира персональных компьютеров и операционной системы Windows. Еще одним важным требованием к универсальному формату является отсутствие финансовых претензий к его использованию со стороны компании-правообладателя.

Формат файла напрямую связан со способами обработки и хранения информации, которая в нем содержится. Для разнородных типов файлов, содержащих сложные виды данных (видео, звук, трехмерные объекты САПР и др.), унификация практически невозможна. Активная разработка некоторых форматов продолжается и в настоящее время, и остановить этот процесс не представляется возможным. Многие форматы закрыты и недокументированны, а авторские права полностью принадлежат компаниям-разработчикам.

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

Формат Adobe PDF

На сегодняшний день довольно сложно найти пользователя, на компьютере которого не был бы установлен Adobe Reader (ранее — Adobe Acrobat Reader). В мире насчитывается более полумиллиарда копий этой программы. Являясь бесплатным продуктом, Adobe Reader входит в установочные комплекты разнообразного программного обеспечения в качестве средства просмотра файлов документации. Технические, научные и финансовые документы, размещаемые в глобальной сети, также принято публиковать в формате PDF (аббревиатура от Portable Document Format).

В формате PDF, созданном компанией Adobe Systems в 1993 году для работы с компьютерными публикациями, используется ряд возможностей языка PostScript. PDF легко переносим, он поддерживается практически всеми аппаратными платформами. Более того, этот формат может напрямую обрабатываться современным профессиональным печатным оборудованием. Программная независимость достигается внушительным списком программных продуктов производства как самой компании Adobe Systems, так и сторонних разработчиков, поставляющих средства просмотра, редактирования и конвертации в PDF из других форматов.

Кроме соответствия стандартным требованиям, предъявляемым к универсальному формату, в PDF реализован ряд дополнительных функций, таких как:

• возможность использования людьми с ограниченными физическими возможностями благодаря встроенной поддержке технологий разметки (JAWS, Window-Eyes и Hal);
• поддержка механизма электронных подписей для защиты и проверки подлинности документов;
• поддержка рецензирования и комментирования;
• поддержка нескольких разных уровней защиты документов.

Перечисленные свойства позволили PDF стать одним из наиболее распространенных форматов хранения и передачи информации. Этому способствует также наличие большого числа программных библиотек и сетевых PDF-принтеров, легко встраиваемых в информационную среду предприятия. Кроме того, немаловажно, что стандарты PDF/X и PDF/A утверждены Международной организацией по стандартизации (ISO). На сегодняшний день многие зарубежные и отечественные компании в качестве стандарта при обмене электронными документами выбрали именно PDF.

Технология использования Adobe PDF

Для эффективной работы с универсальным форматом (далее PDF) необходимо четко определить границы его использования и процедуры конвертации из форматов, в которых исходно разрабатываются документы. Из-за отсутствия такого регламента большинство организаций применяет PDF только для готовых документов, предоставляемых заказчику или типографии, и гораздо реже во внутреннем документообороте. А между тем работа с PDF внутри организации дает ощутимые преимущества.

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

Конвертация «плоских» документов, полученных в текстовых редакторах, электронных таблицах и т.д., никакой сложности не представляет. На данный момент многие приложения обладают встроенными или доступными для установки инструментами конвертации данных в PDF, поэтому эта работа может быть легко автоматизирована и проведена без автора документа на любом этапе разработки.

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

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

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

Благодаря тому что объект (документ) TDMS может хранить произвольное количество файлов произвольного типа, полученный PDF-файл добавляется непосредственно в исходный документ. Система автоматически присваивает файлу PDF свойство «Главный», чтобы в дальнейшем команды просмотра и печати по умолчанию выполнялись над файлом PDF, а не над файлом в исходном формате.

Чтобы избежать хождения документов с файлами только в исходном формате, средства автоматизации TDMS не позволят передать документ без наличия в нем файла PDF. При возврате документа разработчику для внесения изменений PDF-файл будет удален, а исходный файл вновь станет главным.

Работая с файлами в формате PDF, вы улучшаете доступность документов и сокращаете время на их обработку:

• разработанный документ доступен для просмотра с любого рабочего места в организации. Права доступа к нему определяются исходя лишь из соображений безопасности и здравого смысла и не зависят от наличия тех или иных программных продуктов. Для просмотра PDF-файлов в обычном режиме вы можете использовать Adobe Reader или любую другую аналогичную по возможностям ActiveX-компоненту, зарегистрировав ее в TDMS;
• TDMS Viewer обеспечивает просмотр файлов в защищенном режиме без необходимости их перемещения на рабочее место пользователя. Возможность конвертации любых исходных документов в PDF позволяет просматривать в защищенном режиме даже те документы, исходный формат которых не поддерживается TDMS Viewer;
• просматриваемый документ выглядит абсолютно так же, как будет напечатан, что упрощает его проверку;
• после успешно завершенных процедур проверки, согласования и утверждения документ может быть опубликован (укомплектован, отправлен, напечатан) без привлечения его разработчика.

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

TIFF

Еще одним весьма распространенным форматом файлов является TIFF (аббревиатура от Tagged Image File Format). Разработанный в 80-е годы прошлого столетия компанией Aldus, TIFF представляет собой битовый графический формат, поддерживаемый практически всеми приложениями для рисования, обработки изображений и верстки. Формат TIFF поддерживает цветовые режимы CMYK, RGB, градации серого с альфа-каналами, комментарии к изображениям, многостраничный режим, различные алгоритмы сжатия и некоторые другие полезные свойства, предназначенные для работы с изображениями.

Формат TIFF де-факто является стандартом в области сканирования и не нуждается в установке дополнительных программ. Именно это и было положено в основу следующей технологии.

Технология синхронизации бумажных и электронных документов

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

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

Наиболее распространенным способом создания документа является следующая последовательность действий:

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

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

Отказаться от вышеупомянутой практики довольно сложно, процесс внесения изменений требует определенных затрат времени. Полный цикл перевыпуска документа (с возвратом документа разработчику) может занять несколько дней. Учитывая требования непрерывности некоторых процессов строительства, иногда такая задержка просто невозможна.

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

А что делать с исходным электронным документом? Переделывать или оставить как есть? Вносить изменения в исходный электронный документ не всегда оправдано. И дело здесь не только в дополнительных потерях времени:

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

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

Проектные организации, расположенные в непосредственной близости от возводимых объектов (например, предприятия, входящие в градостроительный комплекс), имеют возможность оборудовать площадки современными средствами коммуникации и вносить изменения в электронные документы прямо на объекте.

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

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

Технология комментирования

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

• на любой стадии проверки при обнаружении ошибки документ может быть отправлен разработчику. Если проверка документов осуществляется на бумаге, то, учитывая легкость, с которой можно напечатать новый, исправленный документ, нетрудно предположить, что такой «электронный документооборот» потребляет бумаги значительно больше, чем положено;
• проверка документов, сопровождаемая комментариями в устной форме по телефону или при личной встрече с разработчиком, сопряжена с риском частичной утери информации. Как несложно догадаться, при таком способе общения многие «незначительные» замечания теряются, забываются или, что тоже не редкость, «задвигаются» куда подальше;
• бумажный документ не может одновременно проверяться несколькими людьми, тогда как использование параллельной обработки в некоторых случаях могло бы сократить срок его согласования. Не обходится без потерь и уже после проверки: документ еще какое-то время продолжает находиться у проверявшего его специалиста или в обменном хранилище;
• крайне сложно оценить труд рецензента. Косвенные, незадокументированные оценки «он находит больше ошибок» или «она быстрее проверяет» вряд ли будут приняты на рассмотрение.

В отличие от процесса рецензирования на бумаге, комментирование в электронном виде ¹ не затрагивает исходного документа (в противном случае этот процесс должен был бы называться редактированием) — рецензия накладывается «поверх» него. Электронный комментарий создается в специальном редакторе, который обеспечивает ввод текста и графических объектов, создаваемых как для привлечения внимания автора, так и для черчения несложных пояснительных схем.

Программы, предназначенные для просмотра и рецензирования, делятся на две основные категории: одни из них создают комментарии непосредственно в файле исходного документа (например, Microsoft Word), другие сохраняют комментарии в отдельном файле собственного формата (например, Autodesk VoloView). Независимо от используемого способа хранения комментария, важнейшей функцией комментирования в электронном виде является возможность отказа от любых внесенных правок и замечаний.

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

Проблема

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

Решение

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

Проблема

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

Решение

Исследования, проведенные одним из крупных европейских центров проектирования, показали, что использование на рабочем столе двух современных мониторов с большой диагональю повышает производительность труда при проверке технических документов на 10−35%. При стоимости дополнительного монитора от 10 до 30 тыс. рублей срок окупаемости этого решения — от нескольких недель до нескольких месяцев.

Проблема

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

Решение

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

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

Чтобы было понятнее, о чем идет речь, опишем процесс комментирования по шагам.

1. Получив в почтовом сообщении направленный на проверку документ, рецензент выполняет на нем команду Комментировать. Эта команда создает новый информационный объект типа «Комментарий», копируя в него файлы из исходного документа. В дальнейшем рецензент работает только с копиями файлов, сохраненных в комментарии. Заметим, что если не выделить комментарий в самостоятельную сущность, может возникнуть весьма распространенная ошибка. Внесение комментариев непосредственно в переданный на проверку или согласование документ недопустимо, поскольку порождает правовую проблему. Разработчик документа не может нести ответственность за содержимое отредактированного документа.
   Созданный комментарий наследует часть прав доступа, определенных в исходном документе. Пользователи, обладающие правом на просмотр файлов документа, смогут увидеть комментарии к нему. Правом на редактирование комментария обладает создавший его пользователь.
   
2. Находясь в начальном состоянии, комментарий может многократно редактироваться. Это удобно при рецензировании сложных чертежей и больших текстов. Отредактировав файлы комментария, проверяющий специалист выполняет команду Завершить комментирование и переводит комментарий в конечное, фиксированное состояние. Изменять комментарий в этом состоянии уже нельзя. Используя определенные в системе команды маршрутизации, рецензент возвращает документ разработчику.
3. Получив документ, разработчик знакомится с рецензией и принимает решение о способе внесения исправлений. В идеале, чтобы снова приступить к редактированию, разработчик должен создать новую версию документа. Поддержка версий на этапе разработки сохраняет историю разработки и обеспечивает возможность возврата к предыдущему состоянию.
4. Если количество исправлений невелико, их можно исправить в файле исходного документа. Если правок много, вносить исправления лучше в файле комментария, предварительно заменив им исходный файл документа. Для упрощения процедуры замены файла используется специальная команда Обновить исходный файл, выполняемая на комментарии.
5. Процедура комментирования может выполняться произвольное количество итераций, в том числе и параллельно несколькими рецензентами.

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

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