Диссертация (1145120), страница 26
Текст из файла (страница 26)
Для визуального и предметно-ориентированного моделирования эти вопросы изучены далеко нетак основательно, и важность предоставления интегральной среды разработки, основанной на визуальном/предметно-ориентированном моделировании, сильно недооценивается.148автоматически контролироваться графическим редактором. Помимо языкаOCL на практике применяют также следующие подходы: в сгенерированномкоде редактора такие ограничения добавляются «вручную», используя механизм вставок (реализованный, например, в GMF — при последующей перегенерации редактора по метамоделям эти вставки сохраняются), либо такиеограничения оставляют в качестве дисциплины моделирования.
Последнийслучайиспользуетсятогда,когдадляреализациипредметно-ориентированного подхода использован стандартный инструмент моделирования — исчерпав его средства настройки, соблюдение оставшихся особенностей предметно-ориентированного языка контролируют регламентами моделирования (ведь код такого средства недоступен!). Однако в этом случаеимеются дополнительные средства, которые мы рассмотрим особо, так какони активно используются в индустриальных проектах.Итак, при использовании в качестве DSM-платформы стандартныхсредств моделирования — UML-пакетов Enterprise Architect, MagicDraw,Umodel и др., а также EAM-инструментов ARIS, Mega, IBM Rational SystemArchitect и пр. — общепринятой практикой является спецификация ограничений корректности для DSM-решений с помощью скриптов, использующихоткрытые программные интерфейсы этих пакетов.
Однако эта индустриальная практика не учитывает системных разработок, связанных с применениемдля этих целей языка OCL. С другой стороны, процесс разработки и использования таких скриптов может быть существенно более эффективным, еслиприменить практики программной инженерии, в частности, конфигурационного управления (Configuration Management) [277]. На решение этих задач инаправлен представленный ниже метод.Остановимся на методике разработки и использования проверочныхскриптов, оставив пока в стороне вопросы использования OCL (последнийможет использоваться, а может и не использоваться, но в любом случае имеется целевой проверочный код в виде скриптов).
Важно отметить, что син149таксически закреплённые (через метамодель и, возможно, через OCLограничения) правила предметно-ориентированного языка контролируютсяпри разработке модели — пользователь просто не может добавить в модельнеправильную сущность, соединить две существующих сущности некорректной (недопустимой) связью и т.д.
Рассматриваемые нами ограничениякорректности контролируются в пакетном режиме, в рамках процесса администрирования моделей. Это связано с тем, что не все стандартные средствамоделирования позволяют программно, из сторонних приложений и, в частности, из проверочных скриптов, обрабатывать события добавления на диаграмму новых сущностей и связей. Более того, в ряде случаев невозможносразу определить, является ли данная сущность некорректной или нет — этоможет зависеть, например, от значения её стереотипа, которое может бытьзадано позднее. Гораздо проще применить парадигму Build Management и регулярно, например, каждую ночь, запускать проверочные скрипты, которыемогли бы выдать список найденных ошибок в стиле отчётов сборки [44].
Приэтом целесообразно иметь доступ к информации об ответственных за отдельные элементы модели с тем, чтобы в случае найденных ошибок в этом элементе имелась бы возможность непосредственно обратиться к определённому человеку с предложением исправить найденные ошибки. Своевременноеисправление ошибок существенно снижает цену их работ по их устранению.Подобные скрипты целесообразно создавать как единое приложение, которое мы далее будем называть валидатор.
Он может иметь единый интерфейсзапуска (возможно, с параметрами, обеспечивающими возможность задатьдля проверки подмножество модели, если последняя очень велика). Валидатор может также строить и общий иерархический отчёт всего сеанса проверки и рассылать его заинтересованным лицам (пример такого отчёта см. в работе [44]). Более того, если модель велика, то, если средство моделированиядопускает многопользовательскую работу, для экономии времени проверкинекоторые скрипты могут запускаться параллельно. Тут нужно заметить, что150скрипты работают с моделью только на чтение, поэтому параллельный доступ, как правило, обеспечить легко.
Возможность запуска ряда скриптов впараллельном режиме может настраиваться, а может быть однозначно запрограммирована. Наконец, скрипты могут запускаться в режиме «по требованию», то есть отдельным разработчиком для его собственного фрагмента модели. Итак, функционирование валидатора целесообразно организовать наоснове парадигмы Build Management [277] с определённым временным интервалом: один раз в сутки, один раз в неделю и т.д. Для разработки соответствующей управляющей части валидатора (запуск скриптов, средства генерации отчётов и пр.) можно непосредственно использовать инструментальные средства управления сборками, например, технологию TFS [294]. Приэтом сама разработка модели может быть организована также средствамитехнологий типа TFS, с назначением ролей для тех или иных рабочих продуктов и отслеживанием процесса их разработки.
Таким образом процедурасоздания и использования моделей будет интегрирована в процесс разработки основного ПО.Приведём примеры видов ограничений корректности визуальных спецификаций.1. Сужение множества допустимых вариантов моделей: язык моделирования и программный инструмент позволяют создавать избыточнонеправильные спецификации, соответственно, эта избыточность является недопустимой и «отсекается» в скриптах. Например, в метамоделикласс «А» имеет потомков «B», «C», «D», «E», и у класса «A» имеетсяассоциация с классом «W».
Это означает, что связи по этой ассоциациис экземплярами класса «W» разрешено иметь всем экземплярам классов-потоков «A». Между тем для экземпляров класса «E» такие связизапрещены, но убирать его из наследников класса «A» нецелесообразно, поскольку все остальные свойства он наследует. Данную ситуациювозможно разрешить на уровне модели, соответственно усложнив её.151Однако подобные усложнения значительно увеличивают объем исложность модели и уменьшают её наглядность и читаемость, что является очень серьёзным ограничением на применимость метамоделирования.
С дальнейшими примерами подобных ограничений можноознакомиться в работе [30].2. Точное указание на присутствие/запрет определённых конструкцийстандартного языка моделирования, а также на наличие у сущностей исвязей нужных стереотипов и других дополнительных свойств.Например, в пакете со стереотипом «Persistent» могут присутствоватьтолько классы, а остальные сущности диаграмм классов не могут(например, другие пакеты, шаблоны). Более того, все присутствующиев таком пакете классы должны иметь стереотип «Persistent». Примерытаких ограничений можно найти в работах [86], [197].3. Динамические ограничения, зависящие от конфигурации объектов,удовлетворяющих данному фрагменту метамодели.
Например, пустьимеется диаграмма классов, задающая адрес с помощью следующихклассов: «Адрес», «Страна», «Область», «Населённый пункт», «Городской район», «Улица». Тогда, если у адреса имеется область, то онадолжна принадлежать той же стране, что и адрес. Если у адреса указанаобласть, то населённый пункт должен принадлежать той же области, впротивном случае он должен принадлежать стране (той же, что и адрес) [31].4. Требования к именам модельных сущностей — это бывает актуально,когда в проекте создаются соответствующие правила и с моделью работает большой коллектив, то есть люди могут нарушать эти требования.5. Требования к расположению элементов модели и диаграммам в репозитории. Данный вид ограничений корректности накладывается не наметамодель (то есть на язык), а на представления моделей (метамодель152представлений).
При этом последняя может не формулироваться явно.В данном случае целесообразно вспомнить, что речь идёт о большихмоделях, следовательно, структура папок репозитория, с которой пользователи работают в браузере модели, должна быть тщательно проработанаи может быть достаточно сложной. Целесообразно контроли-ровать, как пользователи соблюдают эту структуру.