ТЕХНОЛОГИИ КЛИЕНТ-СЕРВЕР
Евгения Веселова, ныне возглавляющего Дивизион программных решений компании IBS (Москва), человека широко известного в программистских кругах России, так и подмывает назвать на американский манер емко и лаконично - "звезда отрасли". Его профессионализм заметен всем. Долгое время он стоял во главе команды разработчиков фирмы "Микроинформ", занимавшейся, в частности, созданием отечественного текстового редактора "Лексикон". (Его продают в "Микроинформе" до сих пор, хотя будущего скорее всего у этого пакета уже нет.) "Лексикон" являлся составной частью интегрированной системы "Мастер" - главного детища Веселова, позволяющего связывать текстовый редактор, базу данных, электронные таблицы при построении автоматизированных информационных систем (ИС). "Подобные задачи стоят передо мной и в IBS. По существу я продолжаю то, чем все время занимался, только на другом уровне", - поясняет Евгений. Этот новый уровень - создание ИС масштаба предприятия. Спрос на такие системы у нас уже отчетливо проглядывается, а коллективов разработчиков, сведущих в премудростях этого дела, еще немного. Поэтому мы обратились к идеологу программных решений компании IBS Е. Веселову с просьбой рассказать об особенностях их построения в модной нынче архитектуре клиент-сервер.
PC Week: Какие основные отличия присущи, на Ваш взгляд, информационным системам масштаба предприятия?
Е. В.: В первую очередь их сложность. Как правило, эти системы имеют по меньшей мере двухуровневую архитектуру (серверная и клиентская части), что требует соответственно и двухуровневого программирования: разработка интерфейсного дизайна на клиентском уровне и структуры базы данных - на серверном. Кроме того, ИС масштаба предприятия зачастую являются территориально распределенными, а значит, разработчикам необходимо продумать ее коммуникационные возможности, способы репликации данных, разумное географическое расположение ее частей. Следовательно, создание таких систем - это далеко не просто программирование. Главное - организовать проект, увязать воедино все задачи предприятия. Это подразумевает присутствие в разработке таких этапов, как системный анализ, консалтинг, администрирование, обучение и лишь 20% чистого программирования. Если оценивать интегрально, то такой проект предполагает решение в несколько раз большего количества проблем, чем в обычной прикладной программе.
Характерной чертой процесса создания ИС масштаба предприятия является наличие модели (прототипа), описывающей в формализованном виде поведение системы. Она позволяет увидеть, на каком информационном поле происходят процессы, какие информационные потоки задействованы на разных этапах. Модель появляется до того, как программисты начнут писать строки кода, и позволяет проектировщикам и руководству предприятия лучше понять друг друга, согласовать все вопросы на ранних стадиях. Она же помогает правильно оценить стоимость проекта. Модель и связанные с ней технологии - это пласт, который отсутствует в чистом программировании. Если говорить о работе нашего Дивизиона, то у IBS в рассматриваемой области есть свои достижения. Есть и белые пятна, которые еще предстоит ликвидировать.
PC Week: Насколько нам известно, в задачи Вашего подразделения входят поиск возможностей для типизации некоторых процессов, формирование библиотеки повторно используемых модулей. Удается ли решить эту задачу?
Е. В.: Предприятия сейчас остро нуждаются в специализированных информационных решениях, адаптированных или разработанных "под ключ" по индивидуальному заказу. Нашей целью является создание именно таких уникальных систем. В то же время мы стремимся выделить из их множества типовые части, типовые модули, коими могут быть и модели, и части информационных полей. Это не привычные подпрограммы или классы. Сложность состоит в том, что если в клиентской части для обеспечения модульности используются известные понятия (визуальные объекты и библиотеки), то для информационного поля еще не существует общепринятых методологий.
Вообще, описание любой системы масштаба предприятия будет полным, если принимаются во внимание как минимум 4 основные модели: информационная (определяет все типы данных), функционально-операционная (описывает потоки и процессы), интерфейсная (включает формы, с которыми оперирует клиент), пространственная (отвечает за архивирование и репликацию данных в нужном месте и в нужное время). Если к этому добавить еще развертку этих процессов во времени и взаимосвязи между перечисленными моделями, то получится сложная многомерная составная структура.
В соответствии с этим разбиением принцип модульности тоже распадается на несколько слоев: модульность на программном уровне, модульность на уровне информационных моделей, визуальных структур, модульность на функциональном уровне. (Для каждого из видов модулей используется соответствующий формализованный способ представления: язык диаграмм Чена, языки IDEF0 и SQL, языки визуального программирования.)
Возьмем одну из наших проектных разработок логическую модель процессинга нефти. В ней хотя и нет ни одной строки программного кода, но содержится очень значимая информация об организации управленческого цикла добычи, переработки и сбыта нефти и нефтепродуктов. Это знание вполне может быть тиражируемым как в целом, так и по частям. Пользуясь специально разработанными объектно-ориентированными методиками информационного и функционального моделирования, мы представляем эти части в виде "модельных модулей". Скажем, модуль "транспортировка" представляет информационную модель и бизнес-процедуры удаленного управления отгрузкой товаров, модуль "платежи" управление финансовыми потоками. Соединение этих и подобных им модулей в единый комплекс дает управленческое решение о связи материальных и финансовых потоков "процессинг". Механизмы замыкания знаний подобного рода в модули (в чем-то напоминающие процедурные и классовые механизмы) имеют совсем иную, нежели в программировании, природу, которую можно назвать объектной системотехникой. Эти проблемы находятся на самом переднем крае технологического фронта, и нам приходится совмещать стандартные промышленные методики с собственными разработками.
PC Week: Легко ли удается найти общий язык с заказчиками, готовы ли они к пониманию и обсуждению этих схем?
Е. В.: Множество клиентов, по нашему опыту общения с ними, представляют собой довольно контрастную картину. Одни до сих пор не понимают, что созданием больших информационных систем нужно заниматься на высоком технологическом уровне (все еще можно услышать: "У нас есть группа собственных разработчиков, они все запрограммируют"). Другие же, пытаясь автоматизироваться собственными силами и получить решение "по дешевке", потратив тем не менее заметные суммы, осознали необходимость и проекта, и его квалифицированной защиты, и обязательность юридической ответственности за качество и поддержку поставленного решения, и значение надежности поставщика решения.
Я убежден, что автоматизацию средней и крупной фирмы собственными силами организации провести невозможно, причем не только по техническим, но и по многим другим причинам. Судите сами.
Считается, например, что собственная группа разработчиков более контролируема, менее накладна по стоимости. На практике все это оказывается не так.
Возьмем контролируемость. Если группа сильна и успешна, то она действительно в состоянии сделать хорошую систему. При этом возникает стремление тиражировать ее, сделать более универсальной. Это идет вразрез с интересами фирмы-владельца, чья деятельность лежит совершенно в другой (непрограммной) области. Чем успешнее оказывается разработка, тем большее противоречие она порождает в работе фирмы. (Про неуспешные же разработки не интересно говорить с любой точки зрения.)
Возьмем стоимость. Содержание собственной группы кажется выгоднее только в начальный момент, когда сумма месячных окладов ее разработчиков сравнивается с многократно большей суммой, запрашиваемой внешней компанией. Но внешняя фирма, владеющая эффективной технологией, тиражируемыми решениями, в конечном счете обойдется дешевле и надежнее.
С Евгением Веселовым беседовала Елена Монахова.
