Новый инструмент для нового “Компаса”
РАЗРАБОТКА ПО
Игорь Якобсон, Илья Якобсон
Перемен требуют наши сердца!
Виктор Цой
Прошло всего пять лет с тех пор, как в статье “Выбор инструмента по «Компасу»” (PC Week/RE, № 41/ 1997, c. 88) мы писали о мучениях, которые испытывает фирма - разработчик делового ПО в процессе выбора инструмента для нового проекта, о том, почему приходится параллельно с развитием старых проверенных решений начинать разработку совершенно новой системы, уже предвидя, что через пару лет дорогие сердцу исходные тексты программ, внедренных на множестве предприятий, будут пылиться в архивах. Умом-то понимаешь, что на смену им придет новое, интересное, более совершенное, но... Столько душевных, умственных и физических сил вложено в текущий проект - даже от одной мысли, что он скоро умрет, становится дурно.
Но что делать! Обстоятельства выше нас. За время развития действующей системы на свет появились новые платформы, технологии развития программного продукта и межпродуктовой интеграции. Грех их не использовать. Да и риск проиграть в недалеком будущем конкурентную борьбу менее сентиментальным коллегам слишком велик. И снова приходится возвращаться к тем же проблемам, которые уже приходилось решать пять лет назад.
Конечно, было бы здорово сохранить в новой системе солидную часть исходного кода старой. Хотя бы часть, связанную с реализацией чисто прикладных алгоритмов (перенести на новую платформу инструментальный код очень трудно). В принципе при тщательной организации разработки это возможно. Примером может служить опыт фирмы “Локис”, сумевшей осуществить такой переход с DOS-платформы на Windows. До сих пор оба варианта системы “ЛокОффис” развиваются синхронно за счет того, что код, изменяемый прикладным программистом, автоматически встраивается инструментальными средствами и в DOS, и в Windows-версию.
Очевидны все выгоды и преимущества примененного “Локисом” подхода к развитию своего ПО. Однако и такой, казалось бы, безупречный метод подключения новой платформы не лишен недостатков.
Во-первых, не удается полноценно использовать все возможности более современной платформы. Как ни старайся, какой совершенной технологии ведения проекта ни придумывай, но необходимость поддерживать параллельно старую платформу вносит свои ограничения.
Во-вторых, как правило, приходится самостоятельно писать многие низкоуровневые части пакета, например всю систему визуализации данных. Не удается полноценно использовать ПО третьих фирм и возможности средств проектирования. В этом есть и несомненное преимущество: всегда приятно держать под контролем существенную часть программного кода. Но стоимость разработки инструментальной части пакета резко возрастает.
Наконец, в-третьих, за долгие годы наращивания функциональности и изменения алгоритмов работы одних и тех же компонентов системы (а в отношении деловых программ отечественные законодатели заставляют нас это делать регулярно) исходный текст покрывается “заплатами”, становится путаным. Хорошо еще, если все эти годы адаптацией конкретной процедуры занимался один и тот же программист (о несбыточные мечты!), хотя и это не панацея. А при обычной кадровой текучке появление ошибок в тех функциях, которые еще недавно работали как часы, становится почти неизбежным.
Поэтому, когда назрела необходимость в создании следующего поколения ПО “Компас”, наши аналитики, внимательно рассмотрев все варианты переноса в новый проект хотя бы части прикладного кода, со вздохом решили начинать все заново. Немаловажной причиной для принятия такого решения послужило и то, что система “Компас”, в отличие от того же “ЛокОффиса”, является конструктором (или, как теперь стало модно говорить, трансформером). И если основная ценность для создателей жестких систем - именно прикладной код, то разработчики конструкторов в первую очередь думают о многофункциональности и эффективности настроечного инструмента. А его, как уже говорилось выше, так или иначе придется переписывать.
В результате преемственность между старой и новой системами выдерживается лишь на постановочном уровне. Впрочем, в полной мере будут сохранены только бизнес-модели отдельных компонентов: складской учет, алгоритмы расчета сдельной оплаты труда и др. Обидно, конечно, что придется в очередной раз тратить время на реализацию одних и тех же прикладных функций, внося в тексты ошибки, на вылавливание которых придется снова потратить уйму сил. Но нет худа без добра! Ведь при этом можно избавиться от всех огрехов старого кода: заплаток, аппендиксов (“сухих” веток алгоритмов), реликтов, возникших некогда из-за несовершенного владения языком программирования, и т. д., а также исправить все недостатки архитектуры и идеологии, выявившиеся в процессе эксплуатации продукта.
Кроме того, при подходе “пишем заново” нам гарантировано полноценное использование новых языков, технологий и платформ. А ведь именно появление на свет таких новинок и послужило одной из причин принятия решения, не прекращая развития старого проекта, начать разработку следующего поколения ПО “Компас” под условным названием “KCom” (“Компас на COM-технологиях”).
Что делать
Современное деловое ПО должно интегрироваться с целым спектром технологий, которые были слабо развиты (а то и просто не существовали) в 1996 г., когда создавался нынешний программный пакет. В корпоративную информационную систему (КИС) надо естественным образом встроить Web-решения. Нужно обеспечить взаимодействие с сотовыми телефонами и пейджерами (хотя бы в виде посылки сообщений), различными системами реального времени, вплоть до станков с ЧПУ. Необходимы поддержка обмена данными в стандартных форматах XML и возможность тесной интеграции с приложениями, написанными другими компаниями.
Кроме того, хотелось бы, чтобы следующая наша статья о муках выбора инструмента вышла не раньше, чем через десять лет (что для современных информационных технологий является синонимом слова “вечность”). Иными словами, перед аналитиками компании была поставлена задача продления жизненного цикла программ. А для этого в “KCom” должны быть заложены возможности адаптации к тем неведомым пока технологическим инновациям, которые, несомненно, появятся через какое-то время.
В процессе эксплуатации комплекса “Компас” возникло желание усовершенствовать и остальные принципы внутренней организации системы. Главная изюминка современного “Компаса” - инструмент трехуровневой настройки “Мастера”. Под тремя уровнями имеются в виду классическая параметризация, визуальная настройка и средства для программиста. Опыт взаимодействия с многочисленными заказчиками побуждает нас сегодня создать на базе “Мастеров” три четко разграниченных между собой уровня представления ПО для конечных пользователей. Тут важно именно слово “четко”, ибо в значительной степени такое разграничение существует и в текущей версии.
Для конечных пользователей это будет жесткая система: из настроечных возможностей им будет доступна только параметризация. Пользователь второго уровня (так называемый администратор приложений, не обладающий программистской квалификацией) получит возможность заниматься “крупноблочным строительством”. Он не должен оперировать такими понятиями, как база данных, таблица, запрос, процедура. Тем не менее ему будет позволено вносить в проект значительные изменения: создавать новые типы (классы) документов, печатные и экранные формы, назначать уже существующие бизнес-процедуры обработчиками событий, происходящих в КИС, и многое другое. “Крупноблочным строительством” такая настройка названа потому, что все нововведения на этом уровне создаются за счет агрегирования объектов, включенных в систему ее разработчиками. В перечень доступных пользователю объектов входят документы и их реестры, справочники, журналы учетных записей (например, журнал хозяйственных операций или журнал-ордер), расчетные алгоритмы, визуальные и печатные формы, динамические отчеты, которые открываются в отдельном окне и постоянно обновляются без запроса оператора по мере изменения состояния информационной системы и т. д. Все настройки делаются исключительно расстановкой галочек и переключателей.
Пользователь третьего уровня - это человек, обладающий квалификацией программиста. Ему будет доступно, образно говоря, “кирпичное строительство”. Средствами визуального инструментария (точнее, его части, недоступной пользователю второго уровня) он сможет создавать новые объекты, а с помощью “Мастеров” описывать алгоритмы их обработки. Когда мы говорим об обработке, мы не ограничиваем себя понятиями предметной области. Программист должен иметь возможность связывать объекты своей информационной системы не только с базой данных, но и с объектами окружающего мира: с информацией, расположенной в Интернете или в другой КИС, а то и в файлах произвольной структуры, хранящихся в узлах локальной сети. Он сможет задать алгоритм обработки сообщений, поступивших по электронной почте или из устройств, функционирующих в режиме реального времени (это могут быть кассовые аппараты, станки с ЧПУ, контрольно-пропускная система и т. п.). Кроме того, пользователь третьего уровня сможет написать на любом языке программирования свой COM-компонент, которому будет позволено вызывать все разрешенные интерфейсы (методы) наших подсистем и обрабатывать регистрируемые ими события.
Говоря о произвольном языке программирования, мы слегка лукавим. Такая возможность действительно будет обеспечена, но мы предполагаем, что для решения подавляющего большинства задач окажется достаточно встроенного языка системы “KCom”, интерпретатор которого имеется в “Компасе” уже сегодня и носит название “Мастер бизнес-процедур”. Естественно, что функциональные возможности этого “Мастера” планируется существенно расширить.
Как делать
Приложение необходимо будет разделить минимум на три слоя: слой данных (как уже было сказано выше, это не только база данных, но и информация, хранящаяся где угодно в произвольных структурах); слой бизнес-логики (сервер приложений) и слой взаимодействия с клиентом. Если мы хотим использовать тонкие клиенты, то слой взаимодействия разбивается, в свою очередь, на две части: представление данных (собственно тонкий клиент, обычно браузер) и так называемый workspace tier. Разница между слоем бизнес-логики и workspace tier заключается в том, что если на первом выполняется программный код, общий для всех клиентов, то на втором реализуется функциональность, специфическая для каждого из них. Любой слой должен работать, ничего не зная о реализации другого, т. е. используя только описание внешнего интерфейса.
Итак, аналитики “Компаса” пришли к выводу о необходимости применения многозвенной архитектуры. Но для того чтобы написать хорошее жизнеспособное приложение, одной многозвенной архитектуры недостаточно. Как заметил в своей книге “Мифический человеко-месяц, или Как создаются программные системы” Фредерик Брукс, “в 40-е годы приложения писали, в 60-е их строили, в 80-е их выращивали”. В третьем тысячелетии мы бы сравнили процесс создания программ с жизненным циклом сложной биологической системы, которая остается собой даже после замены всех ее клеток. Для этого нужна компонентно-ориентированная технология, позволяющая постепенно переписывать весь код, ни на мгновение не нарушая функциональности и работоспособности системы в целом.
При выборе платформы анализировались следующие технологии взаимодействия удаленных объектов: COM, Corba, EJB и .Net. В результате мы остановили свой выбор на самой “свежей” из них. Конечно, такое решение сопряжено с риском. В необкатанной платформе, каковой сегодня является .Net, всегда содержится множество ошибок, ведь методические материалы по ее использованию еще не наработаны и, Бог весть, на что придется наткнуться в процессе программирования! Но, во-первых, .Net - все-таки продолжательница хорошо известного рода COM/COM+, а посему можно надеяться, не так уж сыра даже в момент выпуска первой версии. Во-вторых, очень важно, что в .Net компонентный подход реализован на всех уровнях вплоть до уровня алгоритмического языка. Мы имеем в виду созданный специально под данную технологию язык C#. С одной стороны, это язык более высокого уровня, чем C++. Он обеспечивает простоту и скорость разработки, удобство внесения изменений и чтения кода. С другой стороны, все же очень приятно, что это единственный компонентно-ориентированный язык, в исходный текст которого можно включать вставки на языке более низкого уровня (все на том же C++). Запас карман не тянет! Мы все прекрасно помним, сколько интересных задач удалось реализовать на Си только за счет вставки ассемблерных кусков в его код. Короче говоря, читателям уже ясно, что C# был выбран в качестве основного средства реализации нашей новой системы.
Выбор .Net в качестве платформы позволил сформулировать методы решения еще одной проблемы, с которой сталкивается любой бизнес-конструктор, имеющий богатые настроечные возможности. Выполнение большинства таких программ заключается в основном в интерпретации метаданных, а это плохо сказывается на быстродействии ПО. Для того чтобы избежать потери скорости, в “KCom” реализуется следующий подход.
В рамках эксплуатации комплекса выделяются три фазы: фаза настройки, фаза актуализации и фаза выполнения. На этапе настройки пользователь-администратор имеет дело не с рабочими БД и сервером приложений, а с их “настроечными” копиями. После завершения всех операций по модификации метаданных, вместе с которыми генерируются сценарии (иначе - скрипты) преобразования (о них мы поговорим чуть ниже), наступает фаза актуализации. Здесь на основе метаданных создаются файлы исходного кода, затем компилируемые в MSIL (Microsoft Intermediate Language) средствами .Net. Одновременно проводятся все необходимые модификации баз данных и других внешних по отношению к программному коду объектов. А на этапе выполнения приложения с помощью CLR (Common Language Run-time) интерпретируется уже код MSIL.
Этот подход, собственно говоря, во многом определенный самой идеологией использования C#, все-таки дает некоторое замедление по сравнению с программами, написанными на С++. Но взамен мы получаем существенные преимущества: компилирование метаданных и высокую скорость внесения изменений в программу. Кстати, если уж говорить о быстродействии, то специалистами нашей фирмы проверено: .Net работает в среде Windows быстрее, чем виртуальная машина Java, а последняя сегодня используется в великом множестве проектов. Кроме того, есть еще один момент. За счет предложенной архитектуры можно избежать постоянных проверок актуальности метаданных на этапе выполнения программы. Это будет делаться только во время старта сервера приложений, что также положительно повлияет на быстродействие прикладной системы.
Решению поставленных перед разработчиками задач в немалой степени способствует и событийная модель взаимодействия подсистем и слоев. Подчеркнем, что абсолютно все события будут доступны даже администратору-“крупноблочнику”, вот только модули для их обработки он может брать лишь из предложенного ему разработчиками списка.
Напоследок хочется остановиться еще на одном моменте, находящемся, на первый взгляд, в стороне от тех базовых принципов функционирования нового пакета, которым посвящена данная статья. Однако продолжающиеся дискуссии о системах-трансформерах (см. PC Week/ RE, № , , , /2002) свидетельствуют о том, что большинство разработчиков считают эту проблему весьма актуальной. Речь идет о процедуре обновления пакета у конечного пользователя.
Конструкторы бизнес-приложений - не просто средства разработки (иначе бы и смысла в них не было), это еще и программы, включающие конкретные модели бизнес-процессов. Когда законодательство меняется (в России это происходит очень часто), приходится выпускать новую версию пакета. Вполне естественно, что пользователи предпочитают не заниматься самостоятельной адаптацией своей информационной системы к новым законам, а получать соответствующие версии ПО от разработчика в порядке абонементного обслуживания. Но ведь в комплект стандартной поставки не входит все то, что программисты ИТ-департамента клиента сотворили собственными руками за время эксплуатации системы. Как свести все воедино в режиме автоматического обновления?
В “KCom” будет реализована схема многоуровневой поддержки, базирующаяся на понятии сценариев (скриптов) преобразования. Рассмотрим ее действие на примере цепочки “разработчик - дилер - пользователь”. Очередная версия программы с новой версией метаданных посылается разработчиком дилеру. Тот прогоняет с помощью встроенных в “KCom” средств сценарий по внесению всех своих настроек (например, для созданного им отраслевого решения) в метаданные, полученные от разработчика. Заметим, что по мере того, как дилер делал в прошлом свои настройки, сценарий всех преобразований автоматически сохранялся. Выполнив его, каждый из них получит новую версию своей КИС. Возможно, что некоторые из его действий, вполне корректных для предыдущей версии метаданных, не будут применимы к новой редакции приложения. В этом случае не обойтись без вмешательства человека. В систему будет входить инструмент автоматического обновления, помогающий пользователю разрешать конфликты версий, а кроме того, мы выработаем правила настроечного программирования, позволяющие предупреждать подобные конфликты.
Созданный таким образом вариант ПО раздается пользователям данного дилера, которые в свое время тоже вносили индивидуальные изменения в базовое решение и сохраняли соответствующий скрипт. При таком подходе уровней преобразования может быть сколько угодно. Например, возможно включение в эту схему дистрибьюторов ПО и/или субдилеров. Нам кажется, многоуровневая поддержка значительно облегчит жизнь всем участникам процесса сопровождения комплекса.
В этой статье мы подвели итоги примерно годичной деятельности группы, занимающейся проектом “KCom”. В соответствии с утвержденными руководством “Компаса” планами первые прикладные модули системы “KCom” увидят свет в сентябре 2003 г.
К авторам - главному эксперту ООО “Компас” канд. техн. наук Игорю Якобсону и архитектору проекта “KCom” Илье Якобсону - можно обратиться по e-mail: sensr@kompac.spb.su и yaxy@compass.spb.ru.
