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

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

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

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

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

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

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

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

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

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

Схема методики валидации больших моделейПерейдём теперь к описанию второй части метода — автоматическому генератору валидаторов по OCL-ограничениям к расширенной метамоделипредметно-ориентированного языка. Принципиальными здесь являются двамомента — метамодель и ограничения.Начнём с метамодели. Обычно средства моделирования имеют собственную модель — тот язык моделирования, который они реализуют.

Эта метамодель отражена, в частности, в структуре программного интерфейса, с помощью которого сторонние приложения (например, проверочные скрипты)имеют доступ к данным из репозитория. Если, например, в метамодели естькласс «Requirement», отвечающий за хранение экземпляров требований, то винтерфейсе также может присутствовать соответствующий класс, имеющийсоответствующие функции и события для доступа к объектам этого класса(это не единственный способ отображения, тем более, что такой интерфейсможет не быть объектно-ориентированным — например, реализованным наJavaScript). Однако в нашем случае, когда мы используем стандартные инструменты моделирования такие как DSM-платформы, текущая метамодельинструмента не подходит, так как на её основе реализован новый (предметно-ориентированный) язык моделирования. В связи с этим, во-первых, разработчики валидатора, планирующие использовать OCL, должны такую метамодель создать, во-вторых, им следует специфицировать отображение этой155метамодели в программный интерфейс используемого инструмента моделирования.

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

Пример расширенной метамодели требованийКласс «RequirementModel» являетя корневым в данной метамодели ивключает в себя требования (класс «Requirement»), представления (класс«View») и папки (класс «Folder»). Класс «Requirement» задает всетребования, присутствующие в модели требований. Класс включает в себяимя требования (атрибут «nameR») и его тип (атрибут «typeR»). Требованиябывают трех видов: бизнес-требования, функциональные требования инефункциональныетребования.СоответственноклассRequirementнаследуется тремя классами:«BusinessRequirement», «FunctionalRequirement»,«Non-functionalRequirement».

Элемент требования может включать вложенные элементы (агрегирование с пометками «Parent» и «Child»): диаграмма156получаетсяпутемдобавлениялистьевкродительскомуэлементу.Составленная таким образом диаграмма может включать в себя вложенныедиаграммы (класс «Diagram»). Представления задаются классом «View».

Онвключает в себя требования (класс «Requirement»). Элементы представленийбывают двух видов — диаграммы и матрицы, то есть класс «View»наследуется двумя классами — «Diagram» и «Matrix». Класс «Diagram»описывает диаграммы, содержащиеся в модели требований. Он включает всебя название диаграмм (атрибут «nameD»). Также класс включает в себятребования (агрегирование с пометкой «parentD»). Связь между диаграммойи требованием имеет множественность «0..1», а со стороны требований —«*». То есть или диаграмма состоит из требований, или она ещё не создана.Класс «Matrix» описывает матрицы, содержащиеся в модели требований. Онвключает в себя название матриц (атрибут «nameM»).

Матрица состоит изтребований (строки и столбцы матрицы задаются агрегированиями спометками «typeM1» и «typeM2»). Матрицы бывают двух видов — матрицасоответствия требований и матрица окружения требования. Поэтому класс«Matrix» наследуется двумя классами — «ConformityOfRequirements» и«EncirclementOfRequirment». Класс «Folder» задает папки, в которыхнаходятся все элементы модели требований.

Папка имеет название (атрибут«nameF») и может включать в себя вложенные папки (агрегирование спометками «Parent» и «Child»). Она также включает в себя представления(класс «View») и требования (класс «Requirement»).После того как метамодель создана, создаются необходимые OCLограничения, реализующие ограничения корректности, которые были сформулированы в данном DSM-проекте. Приведём ряд примеров из DSMрешения Real-IT [33], [321], предназначенного для модельно-ориентированной разработки приложений баз данных, интенсивно работающих с данными,и в разработке которого автор принимал участие.157Пример 1.

Данное ограничение формулирует запрет использованиянаследования для создания потомков неабстрактных классов, что может бытьсвязано с особенностью генерации схемы базы данных по диаграмме классов.На рис. 3.15 представлен фрагмент UML-метамодели, на которыйраспространяется это ограничение.+generalizationGeneralization**+specialization1+parentGeneralizableElement1+isAbstract : Boolean+childРис. 3.15. Фрагмент метамодели для примера OCL-ограничения (пример 1)Ограничение на языке OCL задаётся следующим образом:context Generalizationinv: parent.isAbstractПример 2.

Данное ограничение запрещает использование связей вида«многие ко многим» для классов, представляющих таблицы базы данных, чтосущественно при генерации кода. На рис. 3.16 представлен соответствующийфрагмент метамодели UML.Multiplicity+range11..*+connectionAssociationMultiplicityRange+lower : Integer+upper : UnsignedIntegerAssociationEnd+multiplicity : Multiplicity12..*Рис.

3.16. Фрагмент метамодели для примера OCL-ограничения (пример 2)158Спецификация соответствующего ограничения на языке OCL приведенаниже:context Associationinv: self.allConnections -> select(multiplicityRange->select( upper > 1 ) -> notEmpty).size < 2Следующие примеры приводятся для метамодели, представленной на рис.3.14.Пример3.Данноеограничениеутверждает,чтотребования,присутствующие в модели, должны обязательно содержаться на некоторойдиаграмме. На языке OCL данное ограничение задаётся следующим образом:context RequirementModel inv:self.Requirement -> for All(r: Requirement | r.parentD ->notEmpty())Пример 4.

Данное ограничение утверждает, что имя каждой диаграммыдолжно составляться по следующему принципу: название бизнес-решения,знак « – », строка «Тип требования». На языке OCL данное ограничение задаётся следующим образом:context Diagram inv:Diagram.allInstances() ->forAll(d: Diagram |d.nameD = «Бизнес-решение» +« - » + typeD(d))Пример 5. Данное ограничение утверждает, что диаграммы, матрицы итребования должны располагаться в одной из следующих папок репозитория: «Проекты и изменения\Бизнес-решения\«Бизнес-решение»\ Завершённые проекты и ЗИ\Требования»; «Проекты и изменения\Бизнес-решения\«Бизнес-решение»\Проекты\Требования».Соответствующее ограничение на OCL выглядит следующим образом:159context View--Записываем в строку папки диаграмм и матрицdef: n: String = View.allInstances() -> collect(self.Folder.nameF)--Все диаграммы, матрицы и требования должны находитьсятолько в одной папкеinv: n -> asSet -> size() = 1 and(n = “Проекты\Бизнес-решения\«Бизнес-решение»\ Завершённые проекты и ЗИ\ Требования»or n = “Проекты\Бизнес-решения\БР\Проекты\Требования»)Все ограничения к метамодели с рис.

3.14 сформулированы в табл. 3.3.Рассмотрим теперь генератор валидаторов. В представленной разработкебыл использован Dresden OCL Toolkit [231] для синтаксического разбораOCL-спецификаций. В качестве целевой среды реализации был выбран JavaScript, поскольку он является одним из самых распространённых средствдля разработки скриптов в средствах моделирования. Кроме того, код наэтом языке сравнительно просто интегрируется с программными интерфейсами на COM, .Net и Java (варианты таких программных интерфейсов такжераспространены). Так ведущие UML-средства — Enterprise Architect,MagicDraw, UModel — явно поддерживают JavaScript, ведущие EAMинструменты ARIS и Mega также явно поддерживают JavaScript, IBMRational System Architect поддерживает COM (следовательно, Visual Basic, C#и VBScript).

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

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