 | |
|
Это что касается теории. Действительность же выглядит более мрачной. Вокруг стандартов, необходимых для создания компонентного ПО, всегда разворачиваются весьма оживленные дискуссии, а сами стандарты являются предметом публичного торга. Наиболее ожесточенная конкуренция развернулась между компонентными моделями, разработанными корпорациями Microsoft и Sun Microsystems. Несмотря на частые междоусобные конфликты и отсутствие совершенных технологий, нельзя не отметить, что процедура разработки приложений для бизнеса в последнее время значительно упростилась.
«Несколько лет назад эволюция объектно-ориентированных технологий породила то, что мы сегодня называем компонентным программным обеспечением, - отметил Гради Буч, ведущий эксперт компании Rational Software в области моделирования. - Последние достижения научной мысли имели крайне важное значение для разработчиков приложений. Они позволили поднять планку на более высокий уровень и обеспечили возможность повторного использования ранее созданных программных компонентов».
Гради Буч по праву пользуется огромным авторитетом в области объектно-ориентированного анализа и создания новых методов проектирования программ. Его перу принадлежит целый ряд популярнейших книг, посвященных вопросам объектно-ориентированных технологий и компонентной разработки.
«Повторно использовать нужный вам класс не возбранялось и ранее, но для этого приходилось заново компилировать его, - пояснил Буч. - При применении компонентной технологии достаточно облечь в надлежащую форму некую последовательность битов, после чего ее можно погрузить в уже функционирующую среду. Таким образом, в случае частого изменения операционного окружения (например, при работе с бизнес-правилами) разработчику не придется полностью проходить заново цикл редактирования-компиляции-отладки. Главное - найти необходимые компоненты, а дальше уже без труда можно вставить их в нужное место».
Наличие новых средств компонентного конструирования ускоряет процесс разработки сложных многоуровневых приложений. Но на сегодняшний день производители лишь частично выполнили свои обещания.
Руководство по разработке программных компонентовНа сегодня существуют следующие стандарты компонентного ПО:
|
Интеграторы по-прежнему в цене
Движение в сторону более дружественных средств разработки вовсе не означает, что интеграторы потеряют клиентов. Чтобы убедиться в этом, следует обратиться к истории завоевания рынка программами, построенными по технологии клиент-сервер.
В начале 90-х годов внешние консультанты привлекались в основном для проектирования сложной архитектуры критически важных приложений, необходимых для поддержки деятельности крупных компаний. «Речь идет об архитектуре, - пояснила Барнетт. - Когда людям нужна распределенная среда, они внезапно обнаруживают, что в системе отсутствуют некоторые элементы, которые нельзя создать средствами СУБД или монитора транзакций. Поэтому для решения специализированных задач компании привлекают системных интеграторов со стороны».
Интеграторы зарабатывают свои деньги тяжелым трудом. Львиная доля работ выполняется лишь однажды, для конкретного заказчика. Появление в последние несколько лет средств компонентной разработки открыло перед ними реальные перспективы повторного использования кода, что позволит сэкономить время и упростить решение некоторых вопросов.
В результате разработка проекта для клиента Z наделяет исполнителя не только бесценным опытом, но и реально действующими программными компонентами, которые могут использоваться при выполнении проекта для клиента A. Кроме того, разработчики получают возможность поближе познакомиться с типичной организацией бизнес-процессов и овладеть приемами оптимального преобразования определенных последовательностей действий в программный код.
Некоторые крупные компании предпочитают реализовывать проекты, разрабатывая компоненты своими силами, но большинство все же обращаются за помощью к другим организациям. Ведь создавать новые приложения, всякий раз руководствуясь девизом «сделай сам», чересчур утомительно.
Если компания решила все же прибегнуть к помощи внешних источников, логично выбирать в качестве партнеров консультантов и интеграторов. Это особенно важно в тех случаях, когда информационные технологии призваны расширить возможности уже существующих приложений. В конце концов, интеграторы - это те самые люди, которые стояли у истоков корпоративных информационных систем.
Компания SHL Vision Solutions, в которой работает Стивен Фэнджой, выполняет роль одного из таких интеграторов. Фэнджой помогает клиентам настраивать мощное приложение Vision, построенное на основе компонентной технологии и позволяющее повысить эффективность управления крупным бизнесом. Одно из подразделений корпорации MCI Systemhouse недавно приобрело новую версию этого ПО моделирования, разработанного компанией Rational Software. По словам Фэнджоя, многие покупатели Vision используют продукт для расширения функциональных возможностей уже установленных программ.
Внимание прессы приковано к битве корпораций Microsoft и Sun за контроль над технологией Java. Но анализ информации об этом сражении выходит за рамки газетных полос. Обе компании объявили о своих планах совершенствования компонентной модели - методов определения элементов, обеспечения требуемого уровня интероперабельности и взаимодействия между отдельными компонентами.
Компонентная модель JavaBeans, разработанная Sun, в настоящее время получила мощного и надежного преемника в лице технологии Enterprise JavaBeans. Пока опубликованы лишь спецификации Enterprise JavaBeans, но такие сильные игроки, как корпорация Oracle, уже проявили заинтересованность и собираются интегрировать новую компонентную модель в свои средства разработки.
Объектные технологии: что мешает повторному использованиюПереход компании на объектно-ориентированные технологии зачастую бывает сопряжен с массой проблем, напрямую с технологией не связанных. Именно эти проблемы стали предметом обсуждения на форуме Object World, состоявшемся во Франкфурте в рамках выставки Comdex Enterprise. Большинство сложностей, возникающих вслед за решением приобрести или написать собственное программное обеспечение, основанное на многократно используемых компонентах (reusable components), - управленческие. К такому выводу пришел старший консультант компании LogOn Technology Transfer Джим Эрлоу, принимавший участие в создании библиотеки компонентов для авиакомпании British Airways. «Необходимы изменения в корпоративной культуре, - заметил он, выступая перед не слишком многочисленными участниками форума. - Можно купить программу, но нельзя купить культуру». Многие руководители приходят к пониманию того, что в конечном счете переход к программной технологии, основанной на многократно используемых компонентах, приведет к повышению производительности труда. В подобных ситуациях, по словам Эрлоу, в первую очередь следует ответить на вопрос, насколько серьезны планы повторного использования, поскольку переход на новое ПО потребует времени и денег. По данным Эрлоу, разработка многократно используемых программных компонентов обходится в два-три раза дороже по сравнению с обычными программами. Цикл разработки программного обеспечения удлиняется, в нем появляется по крайней мере еще один этап, что ведет к увеличению общих затрат. Впрочем, если не наделать ошибок, затраты окупятся, пример тому - British Airways. Эрлоу также отметил, что руководству следует установить, какие из переписанных компонентов наиболее существенны для решения стоящих перед предприятием задач. «В реальной жизни так случается далеко не всегда, - признал он. - Как правило, приоритетность проектов определяют сами разработчики». Эрлоу предостерегает от других распространенных ошибок. При реализации подобных проектов необходимо помнить, что повторное использование не сводится к простому копированию. Если программист переставляет несколько строк кода в десять разных приложений и хоть немного их изменяет, их и поддерживать придется по отдельности. Поэтому нужны полностью независимые блоки, которые без изменений используются в различных программах. В целях повышения производительности труда можно повторно использовать не только программный код, но и документацию на него. Кстати, она должна быть хорошо написана. Если на изучение документации требуется более 15 минут, разработчик, скорее всего, отложит ее в сторону. Чтобы обеспечить активное использование уже написанных компонентов, следует известить об их создании всех заинтересованных сотрудников компании. Неплохим решением, в частности, может быть специальный Web-узел. Поскольку задача комплектования библиотеки компонентов достаточно сложна, Эрлоу рекомендовал направить на ее решение лучших специалистов. Если же проект предусматривает покупку компонентов у другой компании, необходимо удостовериться, что предполагаемый поставщик занимает достаточно стабильное положение на рынке. «Вам придется использовать компоненты в течение долгого времени, и если их разработчик исчезнет, вы окажетесь в неприятном положении», - отметил Эрлоу. Весьма предусмотрительно будет внести в договор положение о том, что в случае банкротства поставщика компания получает право пользоваться ее исходным кодом. Один из участников форума, представитель швейцарской компании Soft Link AG Грегори Отт, задал ведущему вопрос, какой путь предпочтительнее: покупка готовых компонентов или их самостоятельная разработка? «Будьте осторожны, - ответил Эрлоу. - Решите для себя, купили бы вы у этого человека подержанный автомобиль?» - Мэри Элизабет Деамико, Служба новостей IDG, Мюнхен |
«Обе технологии сегодня находятся в состоянии неустойчивого равновесия, в этом нет никаких сомнений, - отметил Буч. - Сторонники обеих технологий стремятся раскритиковать продукты соперника, но ни один из лагерей не имеет на сегодня решающего превосходства».
Индустрия ждет, кто же выйдет победителем из сложившейся ситуации, но аналитики считают, что это произойдет не ранее чем через год. Разработчики же пока склонны отдавать предпочтение архитектуре CORBA (Common Object Request Broker Architecture), разработанной независимым консорциумом Object Management Group (OMG).
Интеграторам потребовалось немало времени и терпения, для того чтобы устранить ошибки конкурирующих стандартов и выработать с клиентами долгосрочные планы создания программного обеспечения на основе компонентной технологии.
«Использование компонентов сокращает время разработки, - подчеркнул Буч, - но эту технологию нельзя рассматривать как универсальное решение на все случаи жизни. Создать сложное приложение за одну минуту все равно не удастся. И все же организации получат возможность проектировать более сложные системы по сравнению с теми, которые встречались на рынке ранее».
Создание модели
Средства моделирования помогают разработчикам отражать реальные бизнес-процессы в программных объектах. Компания SHL Vision Solutions широко применяет технологии моделирования для этих целей, равно как и для решения других задач: например, для сбора и управления информацией о физических объектах - телефонных опорах, трансформаторах и коллекторах.
Одно из подразделений корпорации MCI Systemhouse, занимающееся созданием и поддержкой географических и картографических информационных систем, применяет семейство продуктов Vision для сбора информации о материальных активах телекоммуникационных и сервисных компаний и для быстрого создания приложений, обрабатывающих эти данные.
Средства Vision помогают инженерам-электрикам быстро определять, какие провода подключены к тому или иному полюсу. Типичная программная утилита содержит более 100 подобных классов. Применяя решения Vision, несложно определить, какие клиенты пострадают в случае выхода из строя источника питания.
Основными компонентами программного обеспечения Vision являются база данных Oracle (она используется для хранения различных схем и другой информации, которую нельзя представить в виде таблиц), моделирующее приложение Rose, разработанное корпорацией Rational Software, и программные средства Vision Services, предназначенные для пространственного представления сложных объектов.
«Наши средства нельзя назвать продуктом для конечного пользователя, - отметил технический директор компании Vision Стивен Брокуэлл. - Скорее это технология, позволяющая им самостоятельно решать некоторые задачи. С помощью наших программ можно изменять модель данных, добавлять в нее новые объекты, переопределять базовые классы и создавать новые классы, наследующие их свойства».
Для решения конкретных задач компания Vision предлагает клиентам несколько средств. Во-первых, это базовая технология. Во-вторых, приложения для выполнения специфичных операций (например, для поддержания карты в актуальном состоянии). В-третьих, методический инструментарий (например, методология управления знаниями Vision Works). И наконец, служба поддержки - команда, способная создавать бизнес-приложения на основе средств Vision.
Интеграторы и стандарты моделирования
Обычно интеграторы обращают внимание на стандарты только после получения положительного заключения экспертов и оформления соответствующего разрешения, выдаваемого госорганизациями. В этом случае на основе утвержденных стандартов можно создавать эффективную технологию и решать различные практические задачи.
Новые стандарты моделирования широко используются при компонентной разработке и вызывают большой интерес у крупных интеграторов. Моделирование позволяет разработчикам абстрактно представлять бизнес-процессы и служит основой для написания программного кода компонентов.
Унифицированный язык моделирования UML (Unified Modeling Language) был реализован разработчиками компании Rational Software. Позже к работе подключились интеграторы, в частности, компании MCI Systemhouse и Icon Computing, а также крупные производители программного обеспечения и поставщики услуг: компании Unisys, I-Logix и Oracle. Активное участие в создании UML принимал консорциум OMG.
Почему язык UML привлек внимание интеграторов? Скорее всего, потому, что рынок средств моделирования пересекается с традиционной областью интересов интеграторов - с сетевыми корпоративными приложениями.
Клиенты обращаются к интеграторам (например, к специалистам компаний Icon и MCI Systemhouse), когда им нужна конкретная помощь в налаживании работы тех или иных приложений. Непомерно высокая стоимость обучения в сочетании с затратами на закупку нового оборудования и программных средств заставляет интеграторов искать новые, более дешевые решения и применять при реализации проектов различные языки моделирования. Язык UML должен помочь преодолеть многие барьеры и сыграть в индустрии моделирования роль связующего звена.
Поскольку UML позволяет получить исходный код, одна рабочая группа может воспользоваться результатами труда другой, даже если их модели функционируют в различных средах. Созданием средств, совместимых с языком UML, занимается сегодня и ряд других производителей, среди которых можно выделить компании Microsoft, Compuware и IBM.