Диссертация (1145120), страница 28
Текст из файла (страница 28)
Архитектура генератора валидаторов представлена на рис. 3.17.160Средства поддержкипериода исполненияВходные/выходныеданныеСинтаксический анализПоддержка OCLОграниченияцелостности на OCLМетамодельГенерацияСвязь метамоделисо средствамимоделированияПоддержкасредствамоделированияПоддержкаотчетовДоработкаИтоговыйвалидаторИспользуется Dresden OCL ToolkitИспользуется наш генератор валидаторовПользователь дорабатывает валидаторРис.
3.17. Архитектура генератора валидаторовС помощью Dresden OCL Toolkit [231] получается дерево синтаксическогоразбора для OCL-спецификаций, по которому также проверяется синтаксическая корректность самого OCL-кода и использования метамодели. Далее поэтому дереву осуществляется генерация валидатора. При этом используетсяреализованная в рамках генератора валидаторов на JavaScript библиотека динамической поддержки конструкций OCL (поддерживаются инварианты, основные предикаты и средства работы с коллекциями, а также процедуры иитераторы). Эта библиотека не зависит от средства моделирования.
Следующая динамическая библиотека зависит от используемого средства моделирования и реализует инициализацию работы с репозиторием, а также ряд повторно используемых функций и пр. Было реализовано два варианта такойбиблиотеки — для инструментов Real и ARIS. Для полноценной генерациикода по OCL-ограничениям требуется метамодель (она вводится в формате161XML), а также связывание (mapping) элементов метамодели и программногоинтерфейса средства моделирования. Это связывание формализуется с помощью XML и должно быть выполнено отдельно для каждого DSM-проекта.Связывание задаётся просто, если в DSM-проекте используется метамодельинструмента моделирования, и оказывается достаточно сложным при использовании предметно-ориентированных языков.
В первом случае (использование пакета Real) связывание было простым, во втором случае были использованы аннотации на JavaScript, задающие реализацию метамодели в целевом коде. По этой информации автоматически генератор создаёт «обёртку» вокруг обращений к репозиторию, позволяя осуществлять их в терминахметамодели предметно-ориентированного языка. Итоговый валидатор генерируется как оконное приложение, в котором можно выбрать для проверкинабор ограничений из списка созданных с помощью OCL. У приложениятакже есть простой XML-интерфейс для пакетного запуска валидатора из командной строки.
Этот интерфейс оказывается полезным, если валидатор интегрируется со средствами сборки проекта. Результатом работы приложенияявляется двухуровневый HTML-отчёт: на верхнем уровне перечислены ограничения с маркерами успешности/неуспешности проверки; если при проверке ограничения были найдены ошибки, то можно открыть второй уровень ипроанализировать найденные ошибки детально. Данные для отчётов выдаются также в XML-формате, для того чтобы была возможность использовать ихпроизвольным способом (например, реализовать свои собственные отчёты).Для визуализации отчётов используется библиотека поддержки отчётов.Первая апробация метода проводилась в проекте по разработке семействателекоммуникационных систем, разрабатываемых в пакетах RTST и Real[145], [88].
Модель хранилась в пакете Real. Разработка очередного представителя данного семейства происходила посредством выделения из полноговарианта системы необходимых компонент с последующей их доработкой.Визуальное моделирование использовалось в данном проекте для специфи162кации алгоритмом (применялся вариант конечных автоматов, взятый из языка SDL [285], программный код внутри SDL-символов создавался на языкеAlgol68). На этом же языке описывалась схема приложения — классы объектов, чьё поведение описывалось на SDL. Вопрос со средствами контроля качества и отладки для данного семейства стоял давно, поскольку требования ккорректности модельных спецификаций были высоки: общее количестводиаграмм превышало 200, над спецификациями алгоритмов одновременноработало 5–7 человек, по спецификациям генерировался сложный программный код и стартовая (загрузочная) конфигурация программного обеспеченияраспределённого программно-аппаратного комплекса.
Автором был выполнен анализ требований очередного продукта семейства к корректности создаваемых моделей и сформулирован ряд ограничений к разрабатываемым моделям. С помощью представленного метода был реализован валидатор, который был внедрён в проект и работал в режиме ночной сборки в течение 2-хнедель (более полноценного внедрения не получилось из-за ограничений напроцесс разработки в данном проекте).
В результате было найдено 16 ошибок.Вторая апробация проводилась в проекте, посвящённом моделированиюИТ-архитектуры крупной нефтегазовой корпорации на основе пакета ARIS.Ограничения, созданные с помощью представленного метода, были выполнены для фрагмента проекта — модели требований, представленной нарис. 3.14. Созданные ограничения описаны в табл. 3.3. Параллельно те жеограничения были реализованы непосредственно на JavaScript, без OCL.163Табл. 3.3. Список ограничений к расширенной метамодели требований№123456789НазваниеСоглашение об одинаковыхименахСоглашение о количестведиаграммСоглашение о наличии требований в репозитории/надиаграммеСоглашение о типах матрицсоответствия требованийСоглашение о количествематриц соответствия требованийСоглашение о требованиях вматрице окружения требованияСоглашение о количествематриц окружения требованияСоглашение об именах диаграммСоглашение об именах матриц соответствия требований10Соглашение об именах матриц окружения требования11Соглашение о расположениидиаграмм, матриц и требований в папках репозиторииКраткое описаниеТребования одного типа не должны иметь одинаковые именаВ модели должно быть не больше одной корневойдиаграммы каждого вида, то есть состоящей либо избизнес-требований, либо из функциональных требований, либо из нефункциональных требованийВ модели не должно быть требований, которые неприсутствуют ни на одной диаграмме требованийМатрицы соответствия требований бывают трёх типов:бизнес-требования — функциональные требования,бизнес-требования — нефункциональные требования,функциональные требования — нефункциональныетребования.
Других вариантов быть не можетМатриц соответствия требований каждого типа неможет быть больше однойМатрица окружения требования должна иметь делотолько с одним типом требованийМатриц окружения для требования каждого типадолжно быть не больше однойНазвание диаграммы имеет следующий формат:название системы, знак «–», строка «Тип требования»Название матрицы соответствия требований имеетследующий формат: название системы, знак «–»,строка «Матрица соответствия требований», «–» типтребованийНазвание матрицы окружения требования имеет следующий формат: название системы, знак «–», строка«Матрица окружения требования», знак «–», тип требованийДиаграммы и матрицы требований должны быть расположены либо в папке «Проекты и изменения\Системы\Завершённые проекты\ Требования»,либо в папке «Проекты и изменения\ Системы\Проекты\ Требования»Анализ эффективности метода на основе численных метрик был проведёндля второй апробации — объем кода, время исполнения ограничений, сложность разработки.164Объем кода OCL-ограничений составил 78 строк, в то время как объем созданного «вручную» соответствующего JavaScript кода составил 3300 строк.Общий объём кода целевого валидатора (включая средства динамическойподдержки) составил 3600 строк, однако непосредственно код самих ограничений корректности составил 200 строк.Время исполнения сгенерированного кода на репозитории в 27 мегабайт(рабочий репозиторий проекта, содержащий полное описание модели ИТархитектуры корпорации) составило 35 минут.
Созданные «вручную» скрипты работали 26 минут, что объяснялось совместной реализацией ряда ограничений в рамках общих обходов модели. Быстродействие проверялось натестовом окружении, развёрнутом на виртуальной машине. Время работы навысокопроизводительном сервере будет существенно ниже.
Проведём достаточно грубые подсчёты эффективности подхода на реальных моделях, основываясь на примере, рассмотренном в разделе 5.4. В данном проекте былосоздано 10 различных моделей. Если для каждой модели составлять ограничения, подобные тем, которые были составлены для модели требований, ивзять производительность выполнения ограничений для каждой модели за 35минут (худший случай, как указывалось выше), то общее время работы валидатора для всей модели составит 5,5 часов. При этом ряд ограничений можнообъединить и тем самым оптимизировать их выполнение: например, требование о том, что сущность, имеющаяся в репозитории, должна присутствовать хотя бы на одной диаграмме, можно распространить практически, на всесущности в моделях. Совместная проверка этого ограничения для всех сущностей репозитория понизит общее время работы валидатора. Однако дажеэта производительность оказывается приемлемой для работы валидатора врежиме проверки «ночная сборка» — такую проверку можно запускать каждую ночь.
Ещё раз подчеркнём, что реальная производительность на серверебудет существенно выше. Кроме того, производительность можно повысить,запуская ряд скриптов параллельно — валидатор работает с репозиторием165только в режиме чтения, кроме того, EAM-инструменты обеспечивают многопользовательский программный доступ к репозиторию.Сложность разработки OCL-ограничений измерялась по следующей шкале: лёгкая (Л) — использование простых базовых конструкций языка; средняя (Ср) — добавляются итераторы и процедуры; сложная (С) — созданиеобъёмных спецификаций (по 20–50 строк), использование OCL в полномобъёме, активное применение процедур, включая вложенные, широкое использование операторов выборки, различных коллекций и встроенных функций и пр. (примеры таких ограничений см. в работах [197]).
В данном проекте сложных OCL-ограничений не создавалось.166Табл. 3.4. Анализ эффективности подходаНазваниеОбъем OCLограничений(в строках)Время исполненияСложность1Соглашение об одинаковых именах32,42Л2Соглашение о количестве диаграммСоглашение о наличии требований врепозитории/на диаграммеСоглашение о типах матриц соответствия требованийСоглашение о количестве матриц соответствия требованийСоглашение о требованиях в матрицеокружения требованияСоглашение о количестве матрицокружения требованияСоглашение об именовании диаграммСоглашение об именовании матрицсоответствия требованийСоглашение об именовании матрицокружения требованияСоглашение о расположении диаграмм, матриц и требований в репозиторииИтого134Ср25,15Л202,75Ср102,16Ср72,83Ср72,1Ср32,72Л35,78Л65,16Л43,4Л7835,0734567891011Сформулируем преимущества предложенного метода.1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
