Мечты о будущем программирования

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

Наталья Дубова

Имя Айвара Якобсона у многих, наверное, вызовет ассоциацию со знаменитой «тройкой» — Буч, Рэмбо, Якобсон. Эти ученые в середине 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 программным обеспечением в не столь отдаленном будущем придется иметь дело буквально всем, а не только молодым энтузиастам или специалистам с высшим образованием. Чтобы нормально существовать в таком мире, нам нужно программное обеспечение, которое само поможет нам его использовать, которое будет понимать, что вы пытаетесь сделать, и помогать вам, обучая вас, что и как надо делать. Это я и называю активным программным обеспечением. Оно будет повсюду, но мы не станем отказываться и от существующих систем, мы будем строить новый тип программ на базе того, что у нас уже есть.

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

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

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

12.12.2005г