Гибкая сторона силы

Сергей Загурский

Не секрет, что в мире насчитывается несколько десятков крупных и несколько сотен средних и небольших программных продуктов, предназначенных для автоматизации инженерного документооборота проектно­ориентированных компаний. Любая многопрофильная компания­интегратор, работающая на рынке CAD/CAM/CAE, имеет в своем арсенале ПО, обеспечивающее функции управления проектными данными.

В 90­е годы компания Consistent Software (прежнее название компании CSoft) предлагала своим клиентам на выбор три продукта: один — дорогостоящий с мировым именем, другой — иностранный в более дешевой ценовой категории, и третий — продукт российского производителя. Но даже эта практика не смогла преодолеть недостатки применявшихся систем:

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

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

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

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

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

Скрытая угроза

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

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

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

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

Атака клонов

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

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

Хорошо, если поставщик решения обладает дополнительными модулями, которые позволят вам расширить круг решаемых задач. Но, во­первых, это наверняка произойдет не бесплатно, а во­вторых, информационные системы не подчиняются законам аддитивности. Если сложить модули А и Б, получится система В, а не А+Б1. Процесс перехода на новый вариант решения скорее всего будет больше походить на новое внедрение с сохранением старых данных, а не постепенное достраивание системы.

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

Но если не универсальная среда программирования и не готовое решение, то что же?

Новая надежда

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

TDMS была задумана и выполнена как открытое, программируемое, модульное приложение. Система состоит из трех основных логических частей:

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

В качестве идеологической основы мы взяли решения, примененные ранее в Microsoft Office, AutoCAD, SolidWorks, CorelDRAW и др. Данные продукты используют интегрированную среду разработки, обеспечивающую расширение базовых возможностей за счет технологии OLE Automation и языка программирования Visual Basic2. Безусловными преимуществами такого подхода являются скорость разработки, относительно невысокие требования к персоналу, возможность самостоятельной доработки уже функционирующей системы, легкость в обучении. Интегрированная среда разработки платформы TDMS получила название TDMS Developer.

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

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

Конструктор типов объектов

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

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

Для описания типа объекта задаются его атрибуты, типы файлов, способ формирования версий, связи с другими объектами и другие свойства. Чтобы производить действия над объектом, мы определяем набор команд, которые, в дополнение к системным командам платформы TDMS, пользователь сможет над ним выполнить.

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

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

Конструктор форм ввода

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

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

• элементы оформления и управления нужны форме для повышения удобства работы пользователя. Например, рамка может объединить на форме однотипную информацию, а кнопка автоматизировать ввод данных;
• TDMS 4.0 поставляется с набором собственных программируемых элементов ввода и управления данными, выполненных по технологии ActiveX. Главным отличием новых компонентов является большая степень свободы, получаемая разработчиком для программирования их поведения;
• произвольные ActiveX­компоненты сторонних производителей обеспечивают практически неограниченные возможности настройки интерфейса пользователя.

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

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

Редактор выборок

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

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

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

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

Мастер отчетов

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

Мастер создания отчетов TDMS включает следующие стадии подготовки отчета:

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

Реализация последнего пункта в вышеприведенном списке достигается с помощью специализированных программных средств других производителей, тесно интегрированных с TDMS. Поддерживаются три стандартных варианта реализации шаблонов отчетов: Microsoft Excel, Combit List & Labels и SAP Business Objects.

Выбор вышеназванного набора аналитических инструментов неслучаен. Каждый из них обладает определенными преимуществами:

• Business Objects — стандарт де­факто в области бизнес­аналитики, используемый многими компаниями во всем мире. Сегодня это наиболее мощный инструмент для создания и публикации отчетов;
• List & Labels — профессиональный, быстроразвивающийся продукт с очень хорошим арсеналом инструментов, приближающимся по возможностям к Business Objects. Важным доводом в пользу List & Labels служит тот факт, что эта система встроена в TDMS и не требует дополнительных финансовых затрат;
• Microsoft Excel — одно из самых распространенных в мире приложений, используемое большим сообществом разработчиков и обладающие мощными базами примеров и готовых решений.

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

Средства быстрой настройки пользовательского интерфейса

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

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

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

Редактор программного кода

Среда программирования TDMS обладает всеми необходимыми для подобного инструмента характеристиками: многооконный интерфейс, подсветка синтаксиса, справочное руководство с примерами по языку программирования и API TDMS, средства поиска и замены, встроенный пошаговый отладчик, инспектор объектов и другие компоненты визуальной среды программирования.

В качестве языка программирования TDMS использует TDMScript — дополненную препроцессорными расширениями версию интерпретируемого языка Microsoft Visual Basic Script. К расширениям языка относятся, например, инструкция USE, позволяющая использовать программный код любого другого модуля системы; возможность описания функций, доступных для вызова из внешних программных сред; применение локальных переменных среды выполнения и иные возможности.

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

Опыт практического применения

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

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

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

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

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

Сегодня совершенно очевидно, что именно открытость и возможность доработки под свои требования предложенного интегратором «стандартного» решения стали основным фактором выбора TDMS такими ведущими компаниями, как ОАО «Институт Гидропроект», «Институт Теплоэлектропроект», ОАО «Гипрогазоочистка» и многими другими. Кстати, современные решения, построенные на TDMS, уже не ограничиваются только встроенными средствами. На помощь разработчикам приходят среда Microsoft Visual Studio, .NET и язык C#. Но это уже другая история, которую мы вам тоже обязательно расскажем.

Да пребудет с вами сила.  

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

2В настоящее время большинство приложений с открытой архитектурой ориентировано на более современные средства разработки, такие как Visual Studio Tools for Applications. Однако старый добрый VBA все еще в строю, и не только в целях поддержки совместимости. У этой среды много разработчиков и она объективно проще в освоении.

3Генератор запросов преобразует выборку, заданную в графической нотации TDMS, в запрос к базе данных на языке SQL.

САПР и графика 4`2012