Статьи → TDMS 7.0 → TDMS

Вместо предисловия

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

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

У нас действительно накопилось много интересного. Современные решения по TDMS могут быть развернуты в распределенных гетерогенных сетях, включать в себя десятки модулей (это не преувеличение — в дальнейшем мы расскажем о системах, в которых реализовано белее 30 модулей, а с модулями интеграции их число доходит до 50).

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

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

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

Что от нас хотел заказчик…

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

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

1. Сделать максимально простую систему, в которую можно впихнуть практически любые неструктурированные данные.
2. Сделать систему, основанную на стандартах и некотором «наиболее логичном подходе», мейнстриме, постаравшись запихнуть в нее максимально возможное количество вариантов работы компаний по выпуску ПП.
3. Сделать сразу несколько систем, более-менее заточенных на конкретных заказчиков и типы проектов.
4. Сделать систему, которая позволяет разрабатывать другие системы, обладая достаточной гибкостью, чтобы удовлетворить любым текущим и будущим потребностям заказчика.

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

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

…и что получилось в итоге

Давайте перенесемся на 20 лет назад, посмотрим на технологии того времени и поймем, почему TDMS именно такой, а не какой-либо другой.

С точки зрения технологического стека, TDMS представляет собой среду быстрой разработки, объектную программируемую надстройку над реляционной базой данных. Если вы никогда не видели TDMS, но видели Microsoft Access, то вам будет несложно понять, что это за зверь. Замените таблицы на типы объектов, вместо полей у нас атрибуты, добавьте встроенную версионность, умение работать с иерархическими структурами данных, готовое управление правами доступа (через роли и статусы) и вы получите TDMS.

Встроенный язык программирования TDMS — Visual Basic. Но не используемый в Word, Excel и Access Visual Basic for Applications (VBA), а именно Visual Basic Script (VBS). Почему мы не взяли VBA? Это вопрос исключительно коммерческий. Ежегодная стоимость лицензии VBA была достаточно высокой, успешность нового проекта при его запуске всегда лучше оценивать критически. Мы просто не рискнули использовать VBA, тем более что существенных преимуществ он не дает — ему далеко до возможностей компилируемых языков, подключение внешних библиотек ограничено технологией, системных библиотек с открытым кодом немного. С последним у VBS, кстати, значительно лучше — язык часто используется системными администраторами, интерпретатор встроен в ОС Windows. Для него есть множество примеров по программированию взаимодействия как с приложениями, встроенными в Windows, так и с различными прикладными системами.

Применение VBS потребовало от нас создать для него специальную среду, аналогичную применяемой в VBA. В дополнение к более чем 500 методам и свойствам классов прикладного интерфейса программирования (API) TDMS, мы дополнили VBS своими переменными окружения: ThisApplication, ThisObject, ThisScript, CurrentUser и т.п. Для работы с программным кодом на VBS в состав TDMS входит приложение для разработчика и администратора TDMS Developer. Кроме редактора и отладчика программного кода, в TDMS Developer встроены средства управления конфигурацией и администрирования системы.

У нас никогда не стоял вопрос: использовать ли СУБД в составе платформы TDMS или нет. Объемы данных крупной проектной организации исчисляются десятками гигабайт, файловые массивы — терабайтами. Выбирая СУБД, мы остановили выбор на системах Oracle и Microsoft. Этот выбор был стопроцентным попаданием в рынок, новых систем нам не потребовалось довольно долго.

Только годы спустя в список СУБД, поддерживаемых TDMS, мы добавили еще одну: Postgres. Отметим, что мы это сделали еще до того, как импортозамещение стало обязательным к исполнению для многих российских компаний, и Postgres появилась даже там, где раньше о ее применении не было и речи. Просто на определенном этапе развития решений на основе TDMS нам потребовалась бесплатная база данных без ограничений по объему, какие имелись и имеются у бесплатных версий СУБД от Oracle и Microsoft.

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

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

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

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

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

Такие приложения, в зависимости от сложности и значимости, могут иметь разные определения, но по сути являются сервисами. Сервисами TDMS являются, например, файловый сервер, веб-сервер, сервис синхронизации с AD, приложение TDM365, модуль управления субподрядом и др. Программирование сервера в основном идет на C# в среде Visual Studio, но сервер также позволяет запускать код на VBS, что значительно облегчает перенос части разработанного функционала систем на сервер приложений.

Такая приятная гибкость образовалась

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

Постепенно из большого разнообразия решений на TDMS, появившихся в то время: архивы конструкторских и проектно-конструкторских организаций, системы для БТИ, системы управления имуществом и ряда других — начало выкристаллизовываться то направление, с которым и станет ассоциироваться современная TDMS.

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

Как мы прокачались до 88 уровня

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

Средства просмотра

Первым дополнительным продуктом к платформе стал встроенный вьювер TDMS Viewer. Это простой инструмент, умеющий просматривать все основные графические форматы, PDF и *.dwg. Он имеет одну важную отличительную особенность: способен смотреть файлы из потока, то есть открывать документы без прямого доступа к файлам. Данная возможность оказалась весьма востребованной на предприятиях с повышенными требованиями к обеспечению информационной безопасности.

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

Средства просмотра встроены в веб-версию TDMS

Средства хранения файлов

По мере роста файловых данных стало очевидно, что хранить файлы только в больших бинарных объектах СУБД — неверно. Вместе с выходом третьей версии TDMS у нас появился свой файловый сервер. Разумеется, две другие возможности по хранению файлов в базе данных и на URL сохранились как для совместимости, так и для большей гибкости. Так, например, шаблоны документов разных видов, файлы сертификатов пользователей и другие типы файлов, которые в какой-то степени являются частью конфигурации, по-прежнему хранятся в СУБД; а, например, файлы с ограниченным доступом, с грифом «Коммерческая тайна» или «Для служебного пользования» могут храниться в специально устроенном хранилище на URL.

Программные интерфейсы

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

Автоматизация выпуска

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

Управление проектами

Система TDMS с самого начала активно развивалась и двигалась от электронного архива в сторону управления проектным производством. Нашим заказчикам потребовалось календарно-сетевое и ресурсное планирование, и как часть системы появился собственный модуль оперативного планирования и управления ресурсами, иногда для простоты называемый модуль «Диаграмма Ганта».

Управление процессами

Одной из главных претензий к TDMS, которую предъявляли нам в основном наши конкуренты, было отсутствие собственного сервера бизнес-процессов. Нет у нас его и сейчас. Почему? Во-первых, никогда не делай сегодня то, что можешь сделать завтра. Во-вторых, если уж серьезно, на рынке с самого начала появилось довольно много серверов процессов, которые методом проб и ошибок, доработав стандарт BPM до реальных требований управления информационными потоками… в один прекрасный день стали доступны для интеграции. Совершенно, так сказать, безвозмездно. И мы предпочли сделать на стороне TDMS «обертку» для чтения нотации BPM и ее перевода в собственный набор сущностей, запуска процессов, визуализации их состояния и т.п.

Графическое изображение хода выполнения процесса в TDMS средствами интегрированного сервера бизнес-процессов

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

Чего еще нет в TDMS 7.0?

Большинству действующих пользователей TDMS 6 и более ранних версий наверняка больше всего интересно, «а что нового в „семерке“?». Каждый раз, готовя такой материал перед выпуском новой мажорной версии, я стою перед выбором: кратко или подробно? Добавить технических подробностей или опустить их? Раскрыть все карты или приберечь пару козырей?

Хорошо, что в рамках статьи можно осветить только самое интересное, описывать все фичи нет необходимости и возможности. За полной информацией прошу вас не полениться и сходить на tdms.ru, а здесь мы только кратко опишем то, что наверняка будет интересно и пользователям, и разработчикам. Итак, что нового?

• Сервер приложений. Большое количество изменений по программированию и настройке. А если новые возможности доступны разработчикам приложений для сервера, — значит новыми возможностями очень скоро воспользуются и пользователи системы, в особенности те, кто применяют веб-версии приложения TDMS.
• Сервер приложений. Одной из наиболее значимых возможностей обновленного сервера является встроенный модуль проведения аудио/видеоконференций. Современные технологии позволяют проводить различные мероприятия с возможностью онлайн-демонстрации и обмена документами в виде ссылок на них в системе.
• Файловый сервер. Поддержка нескольких хранилищ. Разделение ключевых сервисов TDMS в настройках пользователей.
• Windows-клиент. Возможность одновременно работать с несколькими диалогами свойств. В TDMS 7.0 диалоги свойств объектов можно закреплять в главном окне и открывать в немодальном диалоге со своим программным контекстом.
• Windows-клиент. Автоматическое запоминание любых фильтров. Казалось бы, такая небольшая вещь, но как это облегчает и ускоряет работу людей! Странно, что мы не сделали этого раньше.
• Windows-клиент. Новые возможности выборок, в частности, подсветка обновления содержимого. Если у вас есть новые неотработанные задачи, это будет заметно.
• Интерфейсы. Адаптированы новейшие версии Microsoft Office, nanoCAD.

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

Кроме того, предстоит большая работа по переносу дополнительных модулей на сервер приложений. Модуль планирования и управления ресурсами уже перенесен, очередь за модулем автоматизации выпуска ПСД и модулем построения отчетов. Некоторые операции с файлами и тем более подготовки отчетов могут занимать длительное время. Гораздо правильнее передать решение этих задач сервису. А пользователь после их завершения будет получать соответствующее уведомление. Скорее всего, эти модули будут доступны уже в TDMS 7.0. Это общепринятая практика нашей работы. Мы никогда не жадничаем, и, если у нас есть возможность реализовать полезный функционал в текущей версии, мы это делаем.

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

Всего вам наилучшего!