Введение в предметную область проекта

jzuken edited this page Apr 8, 2011 · 2 revisions

Введение

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

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

Понятно, что данный подход к разработке предполагает наличие довольно мощной инструментальной поддержки — визуальные редакторы, генераторы, фреймворки и прочие средства. Первые инструменты начали появляться в начале 80-х годов прошлого века и за это время появилось множество языков в различных предметных областях и инструментов их поддерживающих. Так, например, одними из пионеров в этой области были инструменты ER-Win компании LogicWorks? для построения моделей данных и дальнейшее его развитие BP-Win для моделирования бизнес-процессов. В настоящее время существуют сотни инструментов различных масштабов, функциональности и стоимости лицензий. Среди самых известных можно, пожалуй, выделить Visual Paradigm и Enterprise Architect компании Sparx Systems.

UML

Наиболее активное распространение CASE-технологий началось в середине 90-х годов, когда появился унифицированный язык моделирования UML. За основу языка были взяты методы моделирования, разработанные Гради Бучем и Джеймсом Рамбо. Потом к ним добавился Айвар Якобсон со своим методом для спецификации бизнес-процессов и анализа требований при помощи случаев использования. Вскоре за дело взялся консорциум Object Management Groop и язык был стандартизирован. Стоит отметить, что UML был создан для специфицирования, визуализации и документирования программных систем. Поэтому сам по себе UML не является языком программирования, потому как семантика многих его элементов задана неявно, либо не задана вообще, поэтому автоматически сгенерировать исполняемый код по UML-диаграмме, как правило, невозможно. Существуют расширения (а если быть точнее, то сужения) языка, которые позволяют добиться кодогенерации из него, но об этом позже.

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

Основной заслугой языка UML было то, что в хаос, порожденный сотнями используемых в 90-х годах языков и нотаций, был внесен некий порядок и люди смогли обмениваться знаниями с помощью диаграмм не только в пределах одной компании или исследовательской группы. Для тех, кому не хватает существующих диаграмм, UML предоставляет механизм стереотипов для расширения языка. Однако, 13 видов диаграмм — это довольно много. Есть мнение, что в попытке объять необъятное UML стал большим и неудобным, его нужно долго изучать, хотя на практике реально чаще всего используется лишь небольшое подмножество. К тому же, многие инструменты реализуют стандарт немного по-своему, что приводит к некоторому уровню несовместимости тулов.

###xUML

Одной из разновидностей UML, точнее, его профилем, является язык Executable UML (исполняемый UML). По сути это некое подмножество UML, для которого четко определена семантика всех элементов. Выбор этих элементов делается таким образом, что их хватает для того, чтобы превратить язык в полноценный язык программирования общего назначения. Идеологами данного направления заявляется, что с помощью данного языка система описывается на более высоком уровне абстракции, нежели те, которые дают текстовые языки программирования общего назначения. Причем идет абстрагирование как от самого целевого языка программирования, так и от принятия каких-то архитектурных решений в процессе моделирования. Т.к. семантика всех элементов четко определена, сопутствующие инструменты способны выполнить однозначное преобразование моделей в исполняемый код и даже “выполнять” эти модели. Стоит отметить, что на практике данный подход практически не дает никакого значимого повышения уровня абстракции, поскольку проектировщику все равно приходится работать с такими понятиями, как классы, состояния, переходы, ветвления, циклы и т.п. Более того, например, для оформления некоторого потока управления программы простые переходы от одного действия к другому требуют задания направленных ассоциаций, соединяющих соответствующие объекты, тогда как в “обычных” текстовых языках программирования типа C++ или Java это будет просто закрывающая скобка или точка с запятой. Все это очень часто приводит к тому, что реализовать алгоритм на текстовом языке программирования бывает быстрее и удобнее, чем сделать это же с использованием визуального языка. К тому же требуется длительное обучение проектировщиков как самому языку, так и особенностям использования инструментальных сред.

Model-driven architecture

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

Вычислительно-независимая модель (Computation Independent Model, CIM) описывает общие требования к системе, не должна содержать никаких сведений технического характера, описаний структуры и функционала системы. CIM максимально общая и независимая от реализации системы модель. Спецификация MDA подчеркивает, что CIM должна быть построена так, чтобы ее можно было преобразовать в платформенно-независимую модель. Платформенно-независимая модель (Platform Independent Model, PIM) описывает состав, структуру, функционал системы. Модель может содержать сколь угодно подробные сведения, но они не должны касаться вопросов реализации системы на конкретных платформах. Модель PIM создается на основе CIM.

Платформенно-зависимая модель (Platform Specific Model, PSM) описывает состав, структуру, функционал системы применительно к вопросам ее реализации на конкретной платформе. В зависимости от назначения модель может быть более или менее детализированной. Эта модель создается на основе двух предыдущих.

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

Предметно-ориентирование моделирование

Предметно-ориентированное моделирование (domain specific modeling, DSM) основывается на том факте, что чаще создание нового специального языка и решение поставленной задачи с его помощью можно осуществить быстрее, чем решать ту же задачу с помощью языков общего назначения. Данная идея сильно не нова, скажем, текстовый предметно-ориентированный язык для работы с геометрией под руководством Андрея Николаевича Терехова был создан еще в Algol-68 много лет назад. Мысль очень простая — языки общего назначения ничего не знают про предметную область, поэтому радикально повысить производительность разработчиков сложно. В DSM все ориентировано на выбранную предметную область — и редактор, и генератор, и фреймворки. Это позволяет сильно поднять уровень абстракции создаваемых моделей, перенося разработку с уровня программных конструкций в область терминов предметной области.

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

Переход на DSM позиционируется как аналог перехода на структурное программирование с ассемблерных языков — повышение уровня абстракции с отказом к возврату на нижний уровень. Разработчик видит только модели и работает только с ними. Никто не редактирует машинные коды после того, как компилятор сгенерировал их по коду на, скажем, языке Си. Зачем же редактировать вручную код, скажем, на языке С++ или Java, получаемый генерацией по визуальным моделям? Именно отказ от редактирования ассемблерных кодов и привёл к скачку в продуктивности при переходе от ассемблерных языков к структурному программированию, и идеологами данного направления делается упор на то, что именно те же идеи приносят большой прирост производительности при переходе с визуальных языков общего назначения на предметно-ориентированные в DSM.

По разным оценкам DSM по сравнению с языками общего назначения дает прирост производительности в 300-1000%. Так, Nokia опубликовала результаты применения DSM подхода для разработки мобильных приложений, показывающие десятикратное увеличение производительности. Применение предментно-ориентированных языков для разработки ПО в ВВС США дало трехкратный рост производительности. Исследования, проводимые какой-то неведомой компанией Lucent, показывают рост производительности и снижение затрат в 3-5 раз для начинающих разработчиков и в 10 и более для опытных.

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

В случае с DSM же первычным для разработчика являются модели. Именно в них вносятся все изменения, а код и другие артефакты потом генерируется автоматически (причем кода разработчик может никогда и не увидеть).

Предметно-ориентированные языки бывают как текстовые, так и графические. Текстовые языки известны и применяются уже довольно давно, например в генераторах синтаксических анализаторов типа ANTLR. Также есть поделка компании JetBrains? под названием MPS, в которая плодит текстовые DSL’и в неограниченных количествах и предоставляет инфраструктуру для их совместного использования. В CASE-подходе подобные системы называют metaCASE-системами и создают они уже визуальные предметно-ориентированные языки. В настоящее время из таких систем наиболее известными являются инструменты MetaEdit?+, Generic Modeling Environment и подсистема Eclipse GMF.

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

Конкретный синтаксис — это то, как элементы языка будут отображаться, т.е. их визуальное представление на диаграммах. Чаще всего на данном этапе разработчику языка предлагается либо создать изображение в специализированном графическом редакторе, либо использовать уже готовое изображение (к слову, такой редактор имеется только в MetaEdit?+).

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

На картинке ниже представлен пример графического предметно-ориентированного языка, разработанного в среде MetaEdit?+ для создания приложений для мобильных телефонов. Мы видим, что элементы языка напрямую отражают сущности предметной области — меню, поля для ввода, информационные сообщения, посылку смс и прочее, а ассоциации между ними соответствуют переходам между экранами при работе приложения.

###QReal

На нашей кафедре уже много лет занимаются разработками в области модельно-ориентированной разработкой ПО. Так, были разработаны технологии RTST, ориентированная на разработку телекоммуникационных систем, REAL, которая была ее объектно-ориентированным продолжением и тоже была нацелена на разработку систем реального времени, а также REAL-IT для разработки информационных систем. С 2007 года разрабатывается новая версия инструментария, получившая название QReal.

В данный момент QReal представляет собой CASE-систему с определенным набором графических редакторов. Так, у нас реализовано подмножество диаграмм UML 2.2, редактор бизнес-процессов, редактор требований, сейчас идет работа над графической надстройкой над языком проектирования кристаллов HaSCoL. Инструментарий изначально проектировался так, чтобы избежать проблем, которые в некоем смысле погубили предыдущие версии CASE-средств — например, многоплатформенность, поддержка многопользовательского доступа к системе, т.н. архитектурное астронавтство. Также имеется некий зачаточный набор генераторов.

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

Также QReal можно назвать и metaCASE-системой, поскольку вместе с инструментом мы предлагаем и технологию для расширения его произвольными пользовательскими редакторами. Инфраструктура QReal включает в себя абстрактное ядро, реализующее общую для всех редакторов и элементов диаграмм функциональность, и подключаемых модулей, реализующих специфику конкретных редакторов. Эти подключаемые модули генерируются по метамоделям языков, которых эти редакторы реализуют. Для задания метамодели изначально использовался специальный текстовый язык на основе XML, изображения элементов задавались в формате, являющимся расширением формата векторной графики SVG. В дальнейшем появилась возможность графического задания как метамоделей создаваемых языков (с помощью метаредактора), так и графического представления их элементов на диаграммах (средствами встроенного в QReal графического редактора векторых изображений). Но об этом подробнее чуть позже.

В проекте довольно большую роль играют студенты. Так, помимо изначальных трех дипломов, которые собственно и положили начало QReal, за два последних года было защищено что-то около штук 6 курсовых и несколько дипломных работ. Кроме этого, уже несколько лет организуются студенческие проекты, в которых мы обучаем студентов кроссплатформенному программированию с помощью инструментария Qt (который, собственно, и использовался для создания QReal), а также знакомим их с тем, как могут быть организованы подобные программные системы изнутри, давая соответствующие задачи. В позапрошлом году студпроект был посвящен расширению функциональности CASE-пакета как такового, в прошлом году упор был сделан на повышение удобства работы пользователя и на расширение возможностей QReal как DSM-инструментария.

Так, одной из задач, которые решались в проходившей недавно летней школе, была интеграция QReal с системой контроля версий subversion. Основная идея состоит в том, что было бы здорово уметь версионировать создаваемые модели. В нашей системе сериализация объектной базы данных в памяти на диск осуществляется с помощью некоторого простого текстового XML-формата, причем файлы раскладываются по типам и принадлежности элементов диаграммам, так что хранение их в svn получается довольно таки естественным способом. Было принято решение использовать для этих целей свободно распространяемую библиотеку libsvn, на основе которой работает большинство клиентов subversion. Большая часть времени была потрачена на вопросы, связанные с изучением точек входа в эту библиотеку, со сборкой ее из исходных кодов на нужных платформах, а также организацию удобной для нас объектно-ориентированной обертки вокруг нее (сама libsvn написана на языке C и содержит в себе много технических деталей, которые нам не особо нужны). В итоге мы даже научились программно делать check-out и commit.

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

Несколько задач касались создания и работы с ассоциациями на диаграммах. Так, была добавлена возможность добавления точек излома связей между элементами, просто потащив за какой-либо участок ломаной. Также был реализован подхода к созданию новых связей, ассоциированных с выбранным элементом. При выделении объекта на диаграмме вокруг него появляются несколько разноцветных кружков, каждый из которых ассоциирован с видами связей, которые из данного элемента могут исходить. При нажатии на эти кружки из элемента можно “вытащить” связь. Если пользователь при этом отпускает кнопку мыши на свободном пространстве диаграммы, ему предлагается список элементов, которых можно соединить с выбранным данным типом связи. Если же кнопка мыши отпускается на существующем элементе, система проверяет, можно ли соединить эти элементы выбранным типом связи, и решает, стоит ли создавать данную ассоциацию или нет. Другим крупным направлением, которому была посвящена работа в студпроекте и летней школе, было расширение инструментов поддержки метамоделирования в QReal. В частности, были направлены усилия на создание графического метаязыка, а также инструментальной поддержки для него. Так, был создан метаредактор, позволяющий описывать абстрактный синтаксис создаваемых языков, а также графический редактор векторных изображений, задающих конкретный синтаксис, т.е. представление элементов разрабатываемого языка на диаграммах.

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

Другим интересным направлением исследований в области модельно-ориентированный разработки ПО являются нестандартные интерфейсы взаимодействия с пользователем. Эффективность любого используемого инструмента определяется тем, насколько удобно и быстро он позволяет выполнять те операции, для которых этот инструмент предназначен. В процессе разработки моделей одними из наиболее часто выполняемых действий над объектами на диаграммах являются их создание и удаление. В большинстве CASE-средств для того, чтобы создать нужный объект на диаграмме, необходимо найти его либо на панели инструментов, либо выбрать в меню, а затем указать место на диаграмме, где бы мы хотели этот элемент разместить. Также в большинстве инструментариев возможен вариант создания объектов drag and drop’ом их из палитры элементов соответствующей диаграммы. То есть даже для такой базовой операции, как создание нового элемента, разработчику нужно совершить не только набор чисто механических действий, но еще и, скажем, вспомнить, на какой вкладке палитры или в каком меню находится нужный ему элемент. Автоматизированию данной операции было посвящено еще одно направление работ, выполняемых в летней школе. Предлагаемое решение состоит в использовании жестов мышью: с каждым элементом ассоциируется определенный жест мышью, выполненный с каким-либо модификатором (в нашем случае с зажатой правой кнопкой мыши) и при выполнении этого жеста в данном месте диаграммы создается соответствующий объект. Например, если пользователь на диаграмме случаев использования UML рисует круг, у него создается use case, если рисует эктора — создаётся эктор.

###Планы на будущее

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

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

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

Другое направление развития системы — реализация разного рода генераторов кода. Например, вот буквально на днях в разговоре с Александром Пименовым появилась идея сделать в QReal редактор для алгоритмов обработки стереоизображений в проекте компьютерного зрения 3vi, разрабатываемого в ЗАО “Ланит-Терком”. Также уже довольно давно хочется сделать редактор для описания параллельных программ и генерацию по таким моделям кода с автоматической расстановкой директив компиляции MPI.

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

Режим быстрого прототипирования. На начальных этапах разработки архитектуры чертежи рисуются абы как, обычно ручками на салфетках. Семантика языка моделирования в этот момент не важна, это ещё и не язык, просто визуальное представление мысли в голове архитектора. По мере уточнения архитектуры, тем не менее, возникает потребность формализации, так что чертежи перерисовывают, например, на UML. Круто было бы, если б можно было накидать каких-то абстрактных квадратиков на диаграмму, а только потом уже задать типы для каждого из них, когда проектировщик уже понял, что хочет.

Метамоделирование на лету. Добавление новых и изменение существующих метатипов прямо в процессе создание моделей. Типа прямо в процессе моделирования можно сказать, что вот этот элемент на самом деле не UML-ный класс, а совсем новая сущность типа “боевой вертолет” с такими-то и такими-то свойствами. Все это аккуратно помещается в метамодель, и все редакторы радостно начинают использовать новый язык.

Интерпретация метамоделей. Сейчас метамодель в QReal захардкожена в плагин, подключаемый к CASE-системе. Понятно, что после внесения изменений в метамодель редактора необходима перегенерация его кода и перекомпиляция его в плагин. Что, скажем, для предыдущих двух задач было бы довольно неудобно, поскольку хотелось бы иметь возможность иметь способ быстро и удобно менять метамодель языка прямо во время создания моделей с помощью этого языка. Данное требование можно удовлетворить, если сохранять сами метамодели в репозитории как обычные модели (что мы уже умеем в общем-то делать) и интерпретировать их во время работы системы. Тогда при внесении изменений в метамодель, они сразу будут вступать в силу.

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

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

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

Интегрирование языков. Систему редко удается описать с помощью всего лишь одного языка. Часто хочется создавать модели, определяющие различные аспекты одной и той же системы. CASE-система должна обладать способностью адекватно переиспользовать сущности разных языков и давать пользователю возможность “провязывать” элементы между моделями.

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.