Press Room

Имя Айвара Якобсона у многих, наверное, вызовет ассоциацию со знаменитой «тройкой» — Буч, Рэмбо, Якобсон. Эти ученые в середине 90-х объединили свои идеи в языке моделирования UML для разработки объектно-ориентированных систем

Заслуги этого замечательного человека перед программной индустрией гораздо шире. Достаточно упомянуть, что он фактически является автором архитектуры компонентов, на которой зиждется все здание современного программного обеспечения и из которой вырастает новая концепция сервис-ориентированных архитектур. Якобсон — выдающийся программист, ученый, бизнесмен (с 1995-го по 2003 год занимал пост вице-президента компании Rational Software, а сейчас развивает две собственные компании). Но главная его характеристика определяется, пожалуй, английским словом visioner — провидец, мечтатель, но мечтатель не прекраснодушный, а вполне практичный, знающий, как воплотить свои мечты в жизнь. Захватывающими идеями будущего программного обеспечения Якобсон поделился с участниками московской конференции разработчиков Software Engineering Conference SEC(R). Во время конференции с ним беседовала редактор журнала Открытые системы Наталья Дубова.

Каковы были предпосылки, подвигнувшие Вас на создание языка моделирования?

В конце 60-х я работал в компании Ericsson. Мы разрабатывали новую программно-аппаратную систему коммутации. После того как без особого результата были испробованы несколько различных подходов, я предложил разработать программное обеспечение системы компонентным способом, то есть представить систему с помощью компонентов, взаимодействующих между собой и с внешним миром посредством строго определенных интерфейсов. Однако сделать это с помощью языка Ассемблера, на котором мы тогда писали код, было невозможно. Нам нужен был более мощный язык. И мы разработали диаграммы, которые сегодня в UML называют диаграммами классов. Для того чтобы описать компоненты, мы использовали и целый ряд других технологий, которые впоследствии стали частью UML, в том числе диаграммы последовательности, диаграммы взаимодействия, диаграммы состояний, диаграммы деятельности и т.д. Так что не могу сказать, что мне просто хотелось изобрести что-то. Я придумывал язык для решения вполне практической задачи.

Затем в середине 90-х годов похожие методы стали появляться в других областях. Мои друзья Гради Буч и Джим Рэмбо внесли каждый свой вклад в моделирование. Работа Гради была связана с распределенными системами, параллельной обработкой, Джим занимался объектно-ориентированным моделированием. Так что, объединив свои усилия, мы вместе охватили довольно большую область применения для языка моделирования, получившего название Unified Modeling Language — UML. Понадобилось время, прежде чем UML стал стандартом.

Сегодня продвигаются концепции разработки и архитектуры на базе моделей. А в чем разница между моделированием с использованием UML и MDA?

Могу сказать, что я всегда вел разработку на базе моделей (model-driven development, MDD). Если снова вернуться в прошлое, то мы уже тогда создавали то, что теперь называют «проектная модель», «модель требований», «модель реализации». Мы постепенно переходили от модели более высокого уровня к модели следующего уровня, фактически генерируя код на базе проектной модели в модели реализации. И делали это в течение многих лет, это совершенно естественный способ разработки. Позже в своих работах я ввел новые типы моделей, такие как «модель пользовательского интерфейса», «модель анализа», «модель вариантов использования» (use case). Переходя от одной модели к другой, вы либо детализируете систему, либо поднимаетесь на более высокий уровень абстракции.

Архитектура на базе моделей (model-driven architecture, MDA) продвигается организацией OMG. Единственное, что в этой концепции существенно новое, хотя на самом деле не вполне достижимое, это то, что я называю моделью анализа, а в OMG определяют как платформенно-независимую модель (platform independent model, PIM). Это исполняемая модель, которая автоматически может быть трансформирована в платформенно-зависимую модель (platform specific model, PSM). Она учитывает, на какой платформе вы работаете — .Net, J2EE или какой-либо другой. Но это очень трудная задача, и я не думаю, что у них есть нее для общее решение. В определенных областях, например в телекоммуникационной отрасли, возможно, и есть способы полностью контролировать операционную систему, как это в свое время сделали в Ericsson, разработав собственную операционную систему. В этом случае, когда есть полный контроль над платформой, можно реализовать MDA. Сегодня все мы уже фактически ведем разработку на базе моделей. Но то, что предлагает OMG, — сделать модель анализа формальной, выполняемой и автоматически трансформируемой в модель, отражающую специфику платформы, на самом деле реализовать очень сложно.

Разработка сервисов в рамках сервис-ориентированной архитектуры очень напоминает разработку компонентов. Должны ли появиться принципиально новые технологии и подходы к программированию в связи с переходом к SOA?

Нет. Здесь хитрость состоит в том, чтобы задать правильные сервисы. А это зависит от того, какой способ определения сервисов вы предпочтете — «сверху вниз» или «снизу вверх». Если вы движетесь в направлении сверху вниз, вы создаете новые сервисы, хотя некоторые из них, возможно, уже используются в течение многих лет. Здесь сервис определяется как некая неделимая часть программного обеспечения. Если снова обратиться к моему опыту в Ericsson, то причина успеха нашей разработки состояла в том, что мы смогли сконфигурировать систему из правильных программных компонентов, или сервисов. Но сейчас вы можете также определять сервисы по принципу «снизу вверх», выделяя программные компоненты, которые будут использоваться во многих различных приложениях. По сути, это просто подсистемы, которые мы поддерживаем уже в течение многих лет в UML, в методологии унифицированного процесса. Новизна концепции SOA состоит только в том, что она описывает среду для поддержки сервисов, доступ к которым можно получить из любого приложения, независимо от платформы, на которой выполняются сервисы. А в сервисах как таковых ничего нового нет.

Здесь на конференции Вы представляете свои новые концепции аспектно-ориентированного программирования и активного программного обеспечения. В чем их суть?

Основная идея аспектно-ориентированного программирования состоит в том, чтобы разделить аспекты программного обеспечения. Аспект — это нечто, в чем проявляются интересы одного или нескольких заинтересованных лиц проекта (stakeholder). Например, аспектом может быть вариант использования, функция, опция или обязательный элемент программы. Вариант использования (use case) — типичный аспект. В системе коммутации варианты использования — это выполнение телефонного звонка, запись трафика вызова, тестирование телефонной линии, супервайзинг линий и т.д. Проблема состоит в том, что когда мы доходим до реализации аспектов в компонентах, то в одном компоненте может быть несколько аспектов, и с этим очень сложно работать. Если же есть возможность разделить аспекты на протяжении всего процесса разработки, отдельно их специфицировать, тестировать, кодировать, то мы получим гораздо более простой способ разработки. Для этого необходим не только аспектно-ориентированный язык программирования, который реализует все необходимые механизмы, но и понимание со стороны разработчиков, способность думать в терминах аспектов. Но в результате мы улучшим структуру программного обеспечения и архитектуру программного проекта.

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

Активное программное обеспечение найдет свое применение в любых приложениях. Возьмем, например, банковские системы. Банки хотят ориентироваться на своего клиента. Изучая клиента, вы понимаете его потребности и, реализовав соответствующие бизнес-правила, сможете обслуживать его все лучше и лучше. Но сегодня для этого надо встраивать эти бизнес-правила в код. Для того чтобы изменить код, необходимо время, новый релиз программного продукта выходит с периодичностью примерно раз в год. Я же предлагаю сделать дополнительный уровень на базе существующего программного обеспечения, уровень интеллектуальных агентов, который позволит динамически вносить подобные изменения. Такие агенты уже реализованы для разработки программного обеспечения. Мы создали продукт для поддержки различных ролей в процессе разработки. Агенты для определения вариантов использования, агенты для разработки архитектуры, агенты для создания вариантов тестирования, агенты для выполнения тестов, агенты для управления проектами, агенты для определения подходящих итераций. Агент предложит вам возможность выбора и запомнит ваши предпочтения, чтобы использовать это в будущем. Технология таких агентов позволяет снять с разработчиков значительную интеллектуальную нагрузку, помогает работать согласованно, способствует повышению продуктивности и качества и ускоряет разработку.

Есть ли на рынке другие продукты, которые реализуют эту концепцию?

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

Как Вы оцениваете роль моделей зрелости CMM/CMMI для достижения компанией-разработчиком реального успеха в своей деятельности?

Я думаю, сертификация по CMMI на самом деле хорошая вещь. Она дает возможность проанализировать, что делает компания-разработчик, и улучшить то, как она это делает. Проблема возникает, если вы внедряете принципы CMMI, не поняв до конца, как делать хорошие программы. Сегодня за CMMI берутся компании, которые не знают, как разрабатывать хорошие программы. Под «хорошими» я понимаю прежде всего программы, разработанные компонентным способом.

Каковы сейчас тенденции в развитии инструментария разработки?

Существует несколько поколений инструментов. В 80-х годах разработка велась с помощью CASE-средств, большинство из которых основывалось на устаревших методиках, отделявших данные от функций. Современный инструментарий базируется на компонентах, объектах, UML и т.д., однако и эти средства используются уже в течение 10-15 лет. Думаю, проблема этих инструментальных сред состоит в том, что за время их существования они наполнялись все большим содержанием, и потому их становилось все труднее использовать.

Я уверен, что интеллектуальные агенты способны обеспечить все необходимое в каждой конкретной ситуации в процессе разработки с помощью правил, которые сформулируют специалисты, компетентные в программной инженерии. Думаю, 10-20% доступной функциональности инструментальной среды — максимум из того, что реально нужно сейчас разработчику, а он в большинстве случаев получает гораздо больше. Есть множество возможностей, о которых вам не стоит даже задумываться.

Уверен, со временем среды разработки будут становиться все лучше. Но, чтобы инструментарий совершенствовался, он должен использоваться в разработке. А некоторые приверженцы «скорых» (agile) методов относятся к инструментальным средам даже с некоторой враждебностью. Они не хотят использовать UML, им проще сразу писать код без какого-либо моделирования.
Есть много средств для совершенствования процессов разработки — инструментарий, методологии, модели зрелости. Но программные проекты остаются сложными и часто заканчиваются неудачами.

Каковы Ваши рецепты достижения успеха?

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

Что Вы можете сказать об образовании в области программной инженерии? Что бы Вы посоветовали тому, кто мечтает о карьере в этой сфере, — чему и как надо учиться?

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

Приведу пример из истории Швеции. В середине XVII века шведский король задумал построить самый большой корабль в мире. Он нанял голландских мастеров, поскольку в те времена Голландия славилась своими корабельщиками, и изложил им свои идеи. Голландцы начали работу, а в это время король отправился в Данию и там узнал, что у датского короля уже есть корабль больше, чем он задумал. Вернувшись в Стокгольм, король сказал строителям, что ему нужна еще одна палуба, что корабль должен быть длиннее на 20 метров и т.д. Поскольку в данном случае заказчиком проекта был король, что оставалось делать корабельщикам, кроме как согласиться. Наконец корабль был построен и спущен на воду. Уже во время испытаний оказалось, что судно очень неустойчиво. Тем не менее, он отправился в плавание, но стоило подуть слабому ветру, и корабль затонул. Три столетия спустя корабль достали, затратив на эту операцию огромные средства, чтобы ничего не повредить. Вот вам образный пример программного проекта. Почему? Там были определенные спецификации, заказчик изменял требования, проводилось тестирование, а сопровождение оказалось гораздо дороже, чем предполагалось, потому что корабль просуществовал триста лет и будет дальше храниться в музее. Налицо все характеристики проекта создания программы. И специалисты по программной инженерии должны изучать весь жизненный цикл — определение спецификаций, архитектуру, дизайн, и, конечно, сопровождение, стоимость которого, как правило, значительно выше стоимости разработки.

Проблема в том, что университеты не знают, как этому учить. Насколько я знаю, в сотнях университетов по всему миру изучают UML и Rational Unified Process (RUP). Но в этих программах отсутствует системный подход к обучению разработке, подобный системности RUP в отношении самого процесса разработки. В большинстве других методологий мало общего знания о том, как разрабатывать программы, они, как правило, сфокусированы на реализации, не принимая во внимание другие этапы жизненного цикла, включая определение требований, тестирование и т.д. Поэтому, если бы я мечтал о карьере в программной инженерии, я бы обязательно изучал RUP. Но и он не лишен своих проблем, которые во многом сходны с проблемами инструментария разработки. RUP слишком объемен, его сложно изучать и непросто использовать, постоянно нужно делать выбор, что вам нужно, а что нет. Все это подвергается критике приверженцами «скорых» методов, и я готов согласиться с этой критикой. Действительно, приходится прикладывать много усилий, чтобы изучить RUP, но когда вы овладеете всем этим знанием, вы сможете разработать хороший продукт. RUP доказал, что способен обеспечить эффективность разработки. Изучение RUP — прекрасный путь к освоению принципов программной инженерии.

С чем связан Ваш уход из Rational?

Я присоединился к Rational в 1995 году. В то время мы сделали UML. Многие мои книги издавались при поддержке и продвигались Rational. Одна из книг была посвящена бизнес-моделированию, и в Rational разрабатывались инструментальные средства для реализации этой концепции. До перехода в Rational я продвигал процесс Objectory, идеи которого получили развитие в RUP. И если даже не все, что произошло с этой моей разработкой, меня полностью устраивает, я рад, что она выжила благодаря Rational, иначе моя компания могла бы просто умереть. Многие другие мои идеи также были приняты в Rational, например, продвигаемая компанией разработка на базе ресурсов (asset-based development) во многом основана на моей концепции повторного использования программного обеспечения (software reuse).

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

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

Думаю, это разработка на базе компонентов и UML, две вещи, которые надо рассматривать вместе. Мы не можем реализовать компоненты, не зная, каким образом их представить. А именно это позволяет делать UML. Проблема UML сегодня снова связана с тем, о чем я уже говорил, — он стал слишком большим, слишком сложным в реализации. К сожалению, это не учитывается в разработке UML 2. Поэтому я бы сказал, что компоненты и основные концепции моделирования — самые фундаментальные аспекты разработки. Хотя с практической точки зрения, может быть, еще более важны и наиболее широко распространены варианты использования — средства для описания требований к системе в виде истории о том, как заказчик будет использовать систему для достижения определенной цели. Их надлежащее применение помогло многим добиться успеха, даже если не выполнялись целиком и полностью правила компонентной разработки.

Natalia Dubova,
"Open Systems, December 2005, Issue #12/2005