Разработка на базе моделей

Данная статья — введение и одновременно своеобразный обзор обширной тематической подборки, посвященной проблемам разработки на базе моделей, которая была опубликована прошедшей осенью в журнале IEEE Software.

В процессе написания программы на языке Smalltalk, Java или C#, мы не получаем непосредственно исполняемого кода. Программа транслируется в язык некой виртуальной машины, которая отвечает за выполнение нашей моделью возложенных на нее задач. Впрочем, многие разработчики воспринимают сегодня «модели» по-иному. Зачастую они сравнивают их с черновым эскизом, считая, что моделирование неоправданно усложняет процесс, и потому исключают модели из процедуры разработки реальных систем.

Что такое модель?

Модель — это согласованный набор формальных элементов, описывающих некую сущность (систему, банк, телефон, поезд и т.д.). Модель помогает в решении ряда задач, в том числе:

• организацию обмена информацией между людьми и компьютерами;
• проверку полноты и завершенности системы;
• генерацию тестов;
• приблизительных оценок стоимости и эффективности;
• соответствии стандартам;
• преобразовании спецификации в реализацию.

Каждая модель охватывает определенный круг тем. К примеру, мы можем построить модель функционирования банка, проигнорировав вопросы, связанные с безопасностью и пользовательским интерфейсом, или же смоделировать сочетание этих компонентов. Мы выбираем, какие элементы модель должна описывать, а какие можно исключить, хотя впоследствии, возможно, придется объединять несколько моделей. Если модель представлена на высоком уровне абстракции, то форма ее описания приближается к естественному языку. Таким образом, разрыв между моделью и экспертами, не являющимися специалистами в компьютерах, сокращается.

Кроме того, мы можем представить модель в виде конструкций, которые существуют на некотором уровне языковой абстракции. Модель, описанная на языке Си, «абстрагируется» от реализации вызовов функций и вычисления выражений, оставляя все машинно-зависимые операции (например, распределение регистров) компилятору. Аналогичным образом модель, описанная на языке Unified Modeling Language, проигнорирует организацию связей, возложив принятие соответствующих решений на компилятор модели или человека, занимающегося проектированием.

Рис. 1. Зависимость модели от уровня абстракции языка и степени абстрактности изучаемого предмета. Начиная от абстрактного объекта (например, банка) и абстрактного языка моделирования (например, Unified Modeling Language), мы движемся вниз, заканчивая решением конкретной задачи на конкретном низкоуровневом языке (например, на Java).

Рис. 1 иллюстрирует зависимость моделей от двух параметров: уровня абстракции языка и степени абстракции изучаемого предмета. Ось предмета имеет инвертированную шкалу, что позволяет нам получить достаточно гладкую кривую, в верхней части которой находятся аналитические, а в нижней — конструкторские модели.

Помощь или препятствие?

Модель не обязана быть завершенной. Зачастую графическая модель не содержит кода. Более того, у модели имеется множество представлений, и лишь часть из них относится к числу визуальных. К примеру, мы можем отобразить текущее состояние индивидуального взаимодействия машин на статической диаграмме или же представить динамику этого взаимодействия с помощью диаграммы, отражающей последовательность событий. Ясно, что любой набор представлений в виде диаграмм должен быть согласован с базовой моделью, проекциями которой они являются. Незавершенность и высокий уровень абстракции — не то же самое, что неточность. Не все модели должны обеспечивать практическую реализацию или даже предоставлять формальное описание, но те из них, которые обладают этими качествами, безусловно, сулят дополнительную выгоду в процессе автоматизации.

Для нас модели являются источником повышения производительности труда. Гораздо дешевле написать одну строку кода на языке Java, чем 10 строк на ассемблере.

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

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

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

Более того, разработка на базе моделей потенциально позволяет осуществлять автоматическое преобразование моделей, созданных на высоком уровне абстракции, в исполняемые системы. По этому поводу Бран Селич в статье «Практические вопросы разработки программ на базе моделей» говорит, что методология моделирования является достаточно зрелой, для того чтобы стать мощным рычагом реализации всех аспектов разработки программного обеспечения.

Модели и метамодели

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

Разработка на базе моделей автоматизирует процедуру преобразования моделей из одной формы в другую. Каждую из моделей (как исходную, так и целевую) мы описываем на некотором языке. Язык целевой модели, к примеру, может определять значение удаленного доступа объектов даже в том случае, если язык исходной модели не позволяет делать этого. Необходимо каким-то образом определить два этих языка, а поскольку моделирование представляет собой средство формализации знаний, синтаксис и семантику языка моделирования можно описать, построив в свою очередь его модель — так называемую метамодель. (Греческое слово meta — «между», «после» — обозначает состояние перехода к чему-либо.) Например, стандарт UML представлен также на языке UML (метамодели UML). Таким образом, все вопросы, связанные с точным определением языка, описаны в терминах самого этого языка. В своей статье «Фундамент метамоделирования: основы создания метамоделей» Колин Аткисон и Томас Кюне исследуют технические основы разработки на базе моделей и обсуждают роль метамоделей в соответствующей инфраструктуре.

Функции отображения

Рассмотрим ситуацию, при которой конструктор преобразует прикладную модель с использованием знаний о безопасности транзакций и механизме отката или же упаковывает приложение во встроенную систему, созданную на базе одной микросхемы. Когда мы сталкиваемся с неизбежным, и функции приложения расширяются, или же происходит расширение базовой технологии, повторно использовать знания конструктора становится весьма затруднительно, особенно если речь идет об интегрированной системе. В результате, эти знания теряются; точнее, они оказываются воплощены в коде кем-то, кто скорее всего «сделал бы все по-другому».

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

Концептуальные модели отражают требования, которые затем можно применить к инженерным моделям. В этих моделях требования формулируются с указанием того, как все должно выполняться. Поскольку концептуальные и инженерные модели охватывают разные проблемные области, разработчики моделей редко пытаются связать их друг с другом.

Гибкость MDA

Все метамодели можно представить с помощью стандарта OMG MOF, который позволяет сформировать стандартные определения функций отображения между метамоделями. Соответствующие спецификации, которые предлагается утвердить в качестве стандарта, носят название QVT. Они описывают стандартную схему создания запросов, представлений и преобразования метамоделей, отвечающих требованиям OMG MOF.

Успешные преобразования моделей закладывают фундамент для организации отображения между аналитическими и конструктивными моделями, которые используют разные метамодели. Однако при этом возникает еще один вопрос: ведь функции отображения неразрывно связаны с метамоделями, которые они преобразуют. Это может привести к созданию хранилищ метамоделей, которые связывают вертикальные области (например, телекоммуникации) с технологиями реализации (сложными профилями распределения) или Web-службы с компонентами Java Beans. В результате, мы получаем модели, которые не являются универсальными и допускают смешение языка моделирования с аспектами предметной области. Подобная форма архитектурного несоответствия может повлечь за собой очень серьезные затруднения, которые, как предполагается, можно преодолеть с помощью MDA.

На рис. 1 показано, что моделировать предметные области можно с помощью языков, отличающихся друг от друга по степени абстрактности. Кроме того, есть возможность применять один и тот же язык для моделирования областей на различных уровнях абстракции. Другими словами, моделирование деятельности банка, вопросов безопасности, пользовательского интерфейса и даже операционной системы имеет смысл осуществлять с использованием одного и того же моделирующего языка. Следовательно, функции отображения всегда будут применяться к моделям, представленным на этом языке, что обеспечит расширение области их действия и продление срока службы.

Отбор знаний на едином (высоком) уровне абстракции языка требует завершенности моделей с точки зрения организации вычислений, а это в свою очередь означает, что мы можем построить их, а затем перенести на целевую программную платформу. Эти модели представляются с помощью единых, обеспечивающих выполнение и проведение необходимых преобразований формальных правил, которые сформулированы на основе некоторых подмножеств UML. В каждой модели описание одного факта предметной области располагается в специально отведенном для него месте, даже если этот компонент еще не включает в себя другие определения или механизмы, которые необходимые для запуска моделей в целевой среде.

Это очень гибкая форма разработки на базе моделей, при использовании которой каждая модель размещается отдельно, является завершенной, обеспечивает практическую реализацию и связана с другими моделями.

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

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

Stephen Mellor, Anthony Clark, Takao Futagami, Model-Driven Development. IEEE Software, September/October 2003. IEEE Computer Society, 2003, All rights reserved. Reprinted with permission.

Аббревиатуры, которые полезно знать

OMG: Object Management Group — международное некоммерческое отраслевое объединение, занимающееся созданием и поддержкой интероперабельных спецификаций программного обеспечения.

UML: Unified Modeling Language — отраслевой стандарт визуального языка, который служит для моделирования программных систем.

MOF: Meta-Object Facility — стандарт OMG, который представляет собой центральное звено MDA и предназначен для описания метаданных и управления моделированием. Он регламентирует порядок определения метамоделей с использованием подмножества UML, генерации схем XML для организации обмена информацией и построения API-интерфейсов для манипулирования действующими моделями (например, конструкции UML).

MDA: Model-Driven Architecture — стандарты OMG, регламентирующие правила разработки спецификаций моделей и процедуры их преобразования в другие модели и завершенные системы. Стандарт MDA разграничивает вопросы предметной области, благодаря чему модели, ориентированные на приложения, можно повторно использовать в различных реализациях независимо друг от друга.

PIM: Platform-Independent Model — независимая от конкретной платформы модель не содержит ссылок на связанную с нею платформу.

PSM: Platform-Specific Model — модель, зависящая от конкретной платформы; является результатом объединения модели PIM с теми платформами, с которыми она связана.