Диссертация (1145120), страница 50

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 50)

Пример модели подобласти5.2.2 Программные средстваРассмотрим более детально разработанный РУП-редактор. Его главноеокно представлено на рис. 5.19, а. Была реализована следующая функциональность:69Отметим, что необходимость при верхнеуровневом проектировании видеть структуруразделов приводит к тому, что такие разделы изображаются в виде отдельных графических символов — в противном случае пришлось бы изображать иерархическое дерево(путь даже минимальной глубины — два) в текстовом виде внутри символа классификатора, что очень неудобно — как в реализации, так и в использовании.308 поддержка множества диаграмм; раздельная поддержка трёх нотаций; поддержка диалогов для ввода/редактирования; поддержка сложных фигур; поддержка целостности модели; средства пакетирования решения.Остановимся подробно на поддержке целостности модели.

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

5.19, б. Кроме того, нашредактор контролирует, что проекцией нельзя связать корректность связей —например, он не позволяет связать подобласть и классификатор с помощьюпроекции.Контролируетсятакженаличиенеболееоднойобла-сти/подобласти на диаграмме.309абРис. 5.19. РУП-редактор: а — главное окно; б — пример диалога выборатипов позиций классификатораПри работе с моделью РУП-редактор сохраняет данные как в vsd-файле,так и в модели ОРГ-Мастера. Это делается при стандартном сохраненииVisio (например, при нажатии клавиш «Ctrl+S»). При этом менять модель изОРГ-Мастера в тот момент, когда с ней происходит работа из РУПредактора, нельзя. Таким образом, мы легко получаем одностороннюю синхронизацию из РУП в ОРГ-Мастер.5.2.3 Метод использованияРУП-решение использовалось для создания диаграмм с описанием схемыпредметной области русско-финского приграничного сотрудничества вконтексте сбора информации для разработки соответствующей Web-системы[122], [140].Визуальные модели были нужныдля того, чтобыспроектировать схему (ОРГ-Мастер на тот момент не поддерживалвизуальныхсредствпроектированиямоделей);ограничитьсяпростоMicrosoft Visio было неудобно, так как диаграммы часто менялись, аэлементы нотации оказались сложными — то есть редактирование требовалоспециального функционала.

Кроме того, требовались средства поддержанияцелостности моделей.310Также, созданные модели должны были быть включены в финальныйотчёт по ISS-проекту, а также в многочисленные презентации — то есть онидолжны были быть красивыми.Использование решения было полностью ограничено сроками ISS-проекта,а пользователи — командой ISS-проекта.5.2.4 Программная интеграция с другими средствамиРУП-решение было интегрировано с инструментом ОРГ-Мастер. При этомбыли решены две задачи — генерация модели ОРГ-Мастера по РУП-модели,а также синхронизация из РУП-редактора в ОРГ-Мастер. Обратнойгенерации (из спецификации Visio по модели ОРГ-Мастера) реализовано небыло ввиду экономии ресурсов разработки — так, в частности, пришлось бырешать задачу автоматической раскладки различных графов.Решение задачи синхронизации, то естьподдержка циклическойразработки (round trip engineering), является важной чертой модельноориентированных решений; не имея этой поддержки, такие решенияоказываются трудными в эксплуатации или даже бесполезными.

Важнойхарактеристикой синхронизации РУП-решения и ОРГ-Мастера является то,что она меняет модель во втором продукте лишь локально, в тех местах, гдеизменилась соответствующая информация в первой модели (changepropagation). Остальные части второй модели остаются без изменений. Еслипросто перегенерировать вторую модель по первой, то будет потерянаинформация, которая содержится только во второй модели и отсутствует впервой.5.2.5 Процесс разработкиРазработка решения заняла около четырёх человеко-месяцев. Вся разработка происходила в рамках ISS-проекта. Требовалось как можно скорее получить работающее решение и начать его использовать.311Выработка концепции.

Идея РУП-решения родилась следующим образом. Выбрав в качестве средства проектирования контента Web-системы ISSпроекта пакет ОРГ-Мастер, наша рабочая группа столкнулась с проблемой —моделировать оказалось неожиданно трудно: ОРГ-Мастер является профессиональным средством, рассчитанным на опытных аналитиков, и для того,чтобы успешно его использовать, требуется значительное время на обучение,причём речь идёт не просто об освоении программного средства, а об овладении уникальной техникой моделирования, реализованной в продукте. Кроме того, нам требовалось ещё выработать свой собственный способ применения ОРГ-Мастера именно для нашей предметной области — она существенноотличалась от тех проектов, где ОРГ-Мастер успешно использовался.

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

Но одновременно наши модели разрастались, и оказалось, что вносить в них изменения становится все труднее — нам понадобились составные фигуры, имеющие несколько областей для текстового ввода, размеры этих фигур приходилось часто менять «вручную» (информация вставлялась, удалялась, ис312правлялась), точки соединения фигур с линиями терялись и т.д. Вместе с тему нас кристаллизовался сам язык моделирования, который в конце концовпревратился в язык составления схем моделей ОРГ-Мастера.

Два этих обстоятельства — трудности в создании спецификации в обычном Visio и сформировавшийся визуальный язык — подтолкнули нас к разработке собственногографического редактора. Разработчиками и пользователями РУП-решениябыла наша команда. Для разработки мы выделили двух человек, знакомых спрограммированием. Постановкой задачи и разработкой решения занималсяаналитик (автор данной диссертационной работы), который был ответствененза предметную область и одновременно являлся главным пользователем редактора, а также разбирался в визуальном моделировании (создавал метамодель и генерационные проекции из РУП-решения в ОГ-Мастер) и разработкеПО.

Последнее важно, так как аналитик был способен сформулировать ясныеи выполнимые требования к решению. Кроме того, в работе нам помогалглавный архитектор программных средств ОРГ-Мастера, консультируя нас ввопросах интеграции. Без помощи аналитика и архитектора нам не удалосьбы в столь сжатые сроки получить полноценное решение. Отметим, что сочетание разных экспертиз и ролей по отношению к создаваемому решению влице аналитика ускорило разработку решения. Обычно на практике эти экспертизы оказываются рассредоточенными по разным людям, что замедляетразработку и приводит к большему количеству проб и ошибок: как правило,DSM-решение обладает существенной новизной, что влечёт за собой соответствующие риски — такого продукта либо вообще никто не делал, либоэтот проект нов для коллектива70.

В данном случае этих рисков удалось избежать.Планирование. Разработка языка сопровождалась сбором информациидля контента Web-системы и созданием соответствующих спецификаций в70Этот вид рисков можно добавить к соответствующему списку рисков и трудностей приразработке DSM-решений, представленному нами в рамках концепции обобщённогоDSM-решения.313Visio (пока неформально, без нашего редактора), а также изучением технологии ОРГ-Мастер. Последнюю мы изучали, так сказать, в «полевых условиях», прямо в рамках нашего проекта, ввиду нехватки времени. Важно отметить, что мы не начинали разработку редактора и метамодели до тех пор, пока не почувствовали удовлетворения от наших моделей и получившегосяязыка моделирования.

Сформировавшийся язык мы зафиксировали метамоделью. Создавать метамодель и тем более редактор в ситуации, когда неясныосновные абстракции моделирования, как указывалось в [301], очень неэффективно: переделки занимают существенное время и могут замедлить процесс разработки. Очень важно правильно определить момент, когда следуетперейти от экспериментов с языком к созданию метамодели: здесь важно неторопиться, но и не затягивать — язык всё равно, скорее всего, будет ещёменяться, но его каркас должен быть сформирован, и именно его фиксируетметамодель. Эта метамодель реализуется в редакторе, а после того, как впробной версии редактора создаётся несколько примеров, язык уточняется.Подчеркнём, что в этом итеративном процессе итерируется (то есть уточняется) малая часть языка, а большую предлагается разработать и зафиксировать в первой версии метамодели71.

Создаваемые в процессе разработки языка модели не были примерами — мы пробовали удачно изобразить, представить собираемую для контента нашей Web-системы информацию. Этот способ хорошо себя зарекомендовал, но потребовал большого количества рутинной работы: достаточно быстро объем спецификаций зафиксировался по71Автор не готов дать формальных критериев для определения момента, когда следуетфиксировать язык метамоделью и начинать реализовывать редактор.

Тем более, что прииспользовании генерационной DSM-платформы, автоматически создающей по метамодели каркас редактора, ситуация отличается от той, которая была в нашем проекте — быстро получить редактор и попробовать созданные абстракции на примерах важно и оченьудобно. Тем не менее, и в этом случае период создания зрелой первой версии должен присутствовать; преждевременная формализация вообще вредна, даже безотносительно немедленной разработки редактора, так как сковывает незрелую мысль и препятствует необходимым обновлениям. В целом, для каждого проекта на практике можно определитьтот момент, когда уже достаточно собрано информации о предметной области и о языке, иможно переходить к формализации.314объёму и информационному охвату и после этого изменялся незначительно, апри изменениях в языке приходилось вносить многочисленные изменения вовсе созданные с его помощью спецификации.

Характеристики

Список файлов диссертации