Сегодня на повестке дня — парадигма разработки на базе моделей (Model-Driven Development, MDD), в основе которой лежит идея о создании такой модели программной системы, которая может быть непосредственно переведена в исполняемый код. Как и в случае объектно-ориентированного проектирования и разработки, основную деятельность по стандартизации в области MDD ведет некоммерческий консорциум Object Management Group. На четвертой конференции по программной инженерии SEC(R) 2008 выступил активный участник этих процессов, один из самых известных профессионалов в мире разработки программных систем Стив Меллор.
Меллор внес заметный вклад в развитие предшествующих MDD парадигм разработки — в 80-х годах выходили его книги по структурированному проектированию и объектно-ориентированному анализу. Сегодня он является убежденным проповедником идей разработки на базе моделей. При этом Меллор — один из тех, кто сформулировал принципы «скорой» (agile) разработки в знаменитом Agile Manifesto. На SEC(R) Меллор дал комментарии относительно текущего состояния и перспектив MDD, и об общих проблемах разработки программного обеспечения.
Расскажите о вашей работе в OMG.
Я занимаюсь так называемой Model Driven Architecture — это бренд OMG для обозначения концепции разработки на базе моделей. Основная идея MDA состоит в том, чтобы дать возможность создавать программные системы на основе построенных моделей, то есть транслировать модели в конкретные реализации. Но чтобы сформировать для этого полную цепочку необходимых инструментов, нужны стандарты. Возможно, у той или иной компании будет прекрасное решение для того, чтобы строить модели и создавать по ним системы. Но до тех пор, пока это решение не способно взаимодействовать с инструментарием других вендоров, никто не сможет гарантировать пользователям, что оно обеспечит абсолютно все необходимое для полного цикла разработки на базе моделей. Поэтому так важны стандарты.
И MDA — это инициатива по разработке такого рода стандартов, в которой принимают участие компании-члены консорциума. Не так давно был завершен проект по формированию подмножества языка UML, в котором определена семантика выполнения. Это подмножество называется Executable UML Foundation. Идея здесь очень проста. Дело в том, что, в принципе, возможны различные способы создавать исполняемые модели на UML, и разные производители средств разработки используют для этого раличные подмножества этого языка. Но в результате их решения оказываются лишены возможности обмениваться информацией друг с другом. Поэтому необходимо было прийти к соглашению, какое конкретно подмножество языка будет исполняемым.
Вторая, крайне важная часть этой работы призвана дать точное определение, что же на самом деле означает понятие «исполняемая модель» (executable model). Мы не только должны сказать, что это понятие включает в себя классы, машины состояния, набор действий и т.д., но и абсолютно точно определить, что подразумевается под каждым из этих терминов. Возможно, в простых ситуациях и так все будет ясно, но при создании сложных конструкций очень важно прийти к такому соглашению о значениях.
Эта работа была начата около трех лет назад и завершена в сентябре этого года. В результате мы имеем стандарт (хотя ему еще предстоит пройти ряд бюрократических процедур), который определяет подмножество Executable UML Foundation и дает определение, что есть исполняемая модель.
Второе направление моей работы в OMG связано с созданием возможностей конструировать модели, которые действительно смогут делать что-либо. UML включает в себя варианты использования (use case), диаграммы классов, машины состояния, но как перейти от всего этого к реальным действиям, конкретным данным и числам? Для этого необходимы действия (action). Процесс создания таких действий был разделен на две задачи. Первая состояла в том, чтобы определить исполняемые элементы, так называемые модели действий (action model). Эта задача решена уже несколько лет назад, и модели действий стали составной частью новой версии языка моделирования, UML 2. Вторая задача — построить язык действий (action language), работа над ней была начата в сентябре этого года. Потребовалось определенное время, чтобы убедить в необходимости специального, более абстрактного языка действий, чтобы понять, что просто Java здесь нельзя использовать.
И, наконец, нужны возможности трансляции описанных действий в конкретный код. Такой стандарт в OMG уже определен некоторое время назад.
В результате мы сможем, во-первых, конструировать модели на высокоуровневом языке действий, в котором не будут определяться детали реализации на определенных платформах. А затем транслировать эти модели в реализации, учитывающие особенности программной и аппаратной платформы.
На самом деле, в компании, с которой я работал, еще в 1998 году была сделана своя реализация исполняемых моделей. Но миссия OMG состоит в стандартизации этого процесса и предоставлении разработчикам информации о том, что существуют стандарты, позволяющие выстроить цепочку инструментов для разработки на базе моделей и сформировать полноценную исполняемую среду моделирования.
Сколько лет развивается концепция разработки на базе моделей, как она принимается рынком, разработчиками?
Эти идеи существуют уже достаточно давно, еще в конце 70-х годов я работал над проектом, в котором использовались многие из современных концепций разработки на базе моделей. Идею, что можно создать небольшой набор файлов, которые описывают систему, и затем из них сгенерировать саму систему, некоторые называют «метапрограммированием» или «порождающим программированием» (generative programming).
Двадцать лет назад мы сделали специальный CASE-инструментарий, но смогли продать его только для одного проекта. Попытки реализовать ее в других проектах окончились неудачей. Люди не хотели замыкаться на одного вендора, они хотели иметь возможность выбора для формирования полного набора инструментальных средств. Пусть существует много производителей, пусть их решения конкурируют друг с другом, но это даст возможность найти оптимальное решение, а не использовать всякий раз нечто уникальное. По существу, путь к этому был открыт только с стандартизацией UML десять лет назад.
Если же говорить об адаптации этих идей на практике, то она ужасно, чудовищно медленная. Этому есть ряд технических причин, включая отсутствие стандартов, отсутствие полноценного инструментария, способного решать задачу в целом, а не отдельные ее части. Наверно, не хватало хорошего маркетинга. Но есть и еще одна очень важная причина — это незрелость бизнес-моделей для MDD. К разработке на базе моделей будет оставаться настороженное отношение, пока пользователей вынуждают покупать весь инструментарий за большую сумму. Это возможно, когда речь идет о проверенной, хорошо стандартизированной методике, для которой существует открытый конкурентный рынок инструментальных средств. В случае MDD мы пока имеем рынок решений, не все компоненты которых надежно реализованы, нет соответствующих стандартов, и главное, мало положительного опыта реализации в компаниях. В таких условиях у пользователей очень велико ощущение рискованности предприятия, и они редко соглашаются выкладывать суммы подчас в десять раз большие, чем за проверенные инструменты разработки.
Какой здесь может быть выход? Например, предложить клиенту купить инструмент моделирования и возможность, а не сам инструмент, генерировать код на базе моделей. Тогда вместо того, чтобы сразу выложить круглую сумму, он заплатит несколько сотен долларов за каждое рабочее место моделирования и затем будет платить по мере необходимости за средства генерации кода. Тем самым риски для клиента значительно сократятся.
Как вы оцениваете перспективы адаптации MDD?
По моему мнению, высока вероятность, что разработка на базе моделей в ближайшем будущем получит более широкое применение. Что дает мне основания для оптимизма? Во-первых, близка к завершению стандартизация. Во-вторых, сейчас крупные игроки рынка средств разработки вовлечены в этот процесс. Десять лет назад решение для разработки на базе моделей создавала компания из 30 человек. Теперь в этой области работают IBM и другие компании подобного масштаба, причем они не просто интересуются проблемой, а активно вносят вклад в ее решение. И это, на мой взгляд, должно положительно повлиять на развитие и рост рынка.
Недавно Microsoft приняла решение присоединиться к OMG. Что это дает консорциуму и самой корпорации?
Тот факт, что Microsoft является частью OMG, обеспечит хорошую поддержку самой идее построения моделей как части создания программных систем. Пользователи видят, что этим занимается IBM, Microsoft, другие известные компании, и убеждаются в том, что это действительно серьезно. Это не значит, что они уже завтра бросятся использовать MDD в своем бизнесе, но, по крайней мере, они проявят интерес к идее, к тому, что она собой представляет и как это работает.
Я не могу говорить официально за всю корпорацию, но я разговаривал со специалистами Microsoft довольно высокого уровня, и они выражают искреннее желание работать в этой области, поскольку считают, что эти разработки могут принести реальную пользу клиентам Microsoft. А в OMG заинтересованы в том, чтобы привлечь этих специалистов для решения вполне конкретных задач.
Существуют ли другие подходы к реализации разработки на базе моделей, помимо тех, которые продвигает OMG?
Существуют много технологий разработки на базе моделей. Наиболее исчерпывающий труд на эту тему принадлежит Кристофу Сернеки. Это объемная книга, в деталях описывающая множество методов и технологий.
Однако здесь вновь встает вопрос стандартизации. Может быть масса умных идей и мощных инструментов, но без стандартов их успех на рынке весьма сомнителен. Я часто общаюсь с крупными заказчиками, и никогда не слышал, чтобы они упоминали все эти решения.
Однако существует одна технология, которую можно рассматривать как потенциального конкурента MDA. Это так называемые языки предметной области — Domain Specific Language (DSL). Они заслуживают внимание не только потому, что этой технологией занимается Microsoft.
Идея создателей DSL — в конкуренции с OMG MDA. Они считают, что неправильно для моделирования использовать UML, поскольку этот язык носит слишком общий характер. Нужны языки моделирования, приближенные к конкретной отрасли— телекоммуникационной, финансовой и др. Наверно, в этом есть определенный смысл. Однако здесь мы снова неизбежно столкнемся с проблемой частных, нестандартизованных решений, когда нужно будет дополнять язык генератором кода, средствами отладки и другими компонентами, необходимыми для выстраивания эффективной цепочки инструментов.
Мне кажется, что языки DSL и MDA не должны быть конкурентами. Можно строить конкретный DSL на основе базовых технологий MDA, таких как Executable UML Foundation. И тогда вы сможете транслировать модель на таком DSL в модель на Executable UML, что не составит большого труда, после чего использовать все остальные инструменты OMG. Так что лучше не конкурировать, а строить одно на базе другого, используя UML как язык общего плана и DSL как язык, учитывающий отраслевую специфику.
Это также предмет обсуждения с Microsoft, которая в течение долгого времени продвигала идею, что DSL лучше UML, и они должны существовать отдельно. Не знаю, насколько эта точка зрения изменится с приходом Microsoft в OMG, могу только предположить, что в Редмонде тоже осознают неэффективность конкуренции.
Вы являетесь одним из авторов Agile Manifesto, а сейчас работаете над стандартами MDA. Эти две темы не противоречат друг другу? Разве модели нужны в agile-разработке?
Отвечу сначала на второй вопрос. В настоящее время действительно нет необходимости в моделях, все можно сделать, просто написав код. Но почему модели могут оказаться более предпочтительными? Потому что они позволяют выразить больше меньшими средствами. Это хорошо известная идея. Если я хочу запрограммировать некие сложные функции на ассемблере, мне придется написать гораздо больше строк кода и потратить больше усилий, чем если бы я писал на C++ или Java. В свою очередь, если использовать модели в MDA, то одна строка на языке действий эквивалентна семи-десяти строкам на C++ или Java. Таким образом, ваша работа на крупных проектах с использованием моделирования будет гораздо более продуктивной. С помощью моделей вы сможете сделать больше и эффективнее, чем на Java, так же, как на Java — и больше, чем на ассемблере.
Что касается противоречия между agile-методами и MDD. Что привело меня на встречу, результатом которой в конце концов стал Agile Manifesto? В то время я читал о некоторых методиках, которые потом попали в категорию agile, в частности, об экстремальном программировании (XP), видел в них немало хороших идей, но меня беспокоило одно противоречие во взглядах тех, кто отрицал полезность моделей. Неоднократно мне приходилось вести следующий диалог. Мне говорили, что модели плохи, а код хорош, потому что модели нельзя исполнять, а код можно. Хорошо, говорил я, а если предположить, что модели могут выполняться, они будут хорошими? Да, отвечали мне. Но модели могут выполняться, убеждал я, значит, модели — это хорошо? Нет, говорили мне, модели — это плохо, код — хорошо. И так до бесконечности.
Все дело в том, что вы понимаете под моделью. Если рассматривать модель только как некий эскиз системы, а потом писать код, просто устно ссылаясь на эту модель, то позиция отрицания моделей оправдана, поскольку в данном случае модель оказывается просто дополнительной работой, средством взаимодействия между членами группы разработки, но не более того.
Можно относиться к модели как к рабочему проекту (blueprint). Вы разрабатываете детальный дизайн системы и передаете спецификацию для реализации. Но и в этом случае для agile-методов модель не принесет большой пользы. Однако если брать исполнимую модель, то практически все принципы agile оказываются применимыми, например, постоянные обсуждения с заказчиками можно вести, используя модели. Замечу, что нигде в Agile Manifesto мы не увидим слово «код»— там говорится о работающей программе. Но исполнимые модели и есть такие программы, так что никакого противоречия здесь не существует.
Существует ли взаимосвязь между MDD и SOA?
Основополагающей идеей MDA и исполняемых моделей является идея трансляции. Вы должны иметь возможность транслировать исполняемые модели в реализации. Здесь пропущен один этап — это архитектура. Существует множество различных архитектур, и в идеологии MDA я могу взять модель и транслировать ее в любую архитектуру — распределенную, J2EE, многозадачную или однопроцессную, клиент-серверную, трехзвенную или, наконец, в сервисную.
С моей точки зрения, SOA — лишь один из типов архитектуры, в котором нет ничего особенного. Хотя я знаю, что сегодня это очень модно, но мода имеет свойство меняться. В контексте MDA сервисная архитектура — лишь одна из целей трансляции. Когда вы транслируете модели, вы пишете набор правил, который базируется на целевой архитектуре. Таким образом, если вы понимаете правила, вы понимаете архитектуру. С этой точки зрения, SOA — одна из многих архитектур, в которые могут транслироваться модели в контексте MDA.
Несмотря на большое число различных методик и эффективных инструментов разработки, качество программных продуктов остается большой проблемой. Что, по вашему мнению, является определяющим для качества программного обеспечения?
Смотря что мы имеем в виду под «качеством программного обеспечения». Если вы разработали компьютерную игру и хотите продать ее под Рождество, то ошибки в этой программе, которые обнаружит пользователь, сильно повысят риск провала этого продукта на рынке на следующее Рождество. Но если вы строите систему контроля авиаперелетов, речь пойдет не об успехе рождественских продаж, а о необходимости, чтобы все гарантированно правильно работало. Существует множество методов и технологий, чтобы добиваться этого. Например, с моей точки зрения, эффективны agile-подходы, которые дают возможность на самых ранних этапах проекта создать исполнимую модель или код, протестировать их и получить информацию, что все хорошо или есть ошибки. В этом случае шансы построить правильную систему намного повышаются.
Но надо понимать, что проблема качества имеет не только технологическую подоплеку, не менее важны вопросы управления проектом. Менеджмент принимает решение, как строить ту или иную систему, планирует сроки и контролирует их выполнение. И в ошибках менеджмента часто кроется причина провала этих сроков. Здесь снова может помочь управление в стиле agile, которое позволяет дробить большие проекты на короткие стадии и более эффективно реализовать руководство ими.
Что вы думаете о подготовке хороших разработчиков, как их надо учить?
Как мне кажется, вообще очень трудно найти хороших разработчиков. Множество людей, пишущих программы, работают с крайне низкой продуктивностью по сравнению с другими профессиями. Я считаю, что нам нужно не больше разработчиков, а больше квалифицированных разработчиков.
Однако университеты — не самое лучшее место, для того чтобы учить многим из тех навыков, которыми должны владеть хорошие разработчики. В условиях академического обучения нет возможности тестировать программный продукт в реальных условиях, выполнять проекты длительностью в два года, вести реальное управление разработкой, выполнять различные роли в команде проекта, в том числе роль заказчика. Все это можно только смоделировать в контексте трехмесячных задач, но этого недостаточно. В университете надо учить математике, технологиям, основам разработки программного обеспечения, но все остальное набирается только в процессе работы.
Я думаю, компании-работодателю необходимо обращать внимание на два важных момента. Во-первых, надо понять, в чем сильные стороны данного сотрудника, а во-вторых, как развивать и совершенствовать эти качества. Несколько лет назад было общепринято начинать программистом, потом становиться дизайнером, затем аналитиком, затем менеджером. Мне это кажется совершенно неправильным, потому что я знаю плохих программистов, в которых заложены хорошие менеджерские качества, и прекрасных программистов, совершенно неспособных быть менеджерами. Люди, которые начинают программистами и успешно работают, не обязательно должны становиться менеджерами. И здесь роль руководства компаний состоит в том, чтобы выявить, в чем их сотрудники могут преуспеть, и всячески поддерживать их энтузиазм в развитии именно этих качеств и решения с их помощью все более интересных задач. Когда я разговариваю с техническими директорами о том, как построить максимально эффективную команду, я советую им находить настоящих энтузиастов своего дела и выбирать правильные пути развития их квалификации.
