-
Ocl язык объектных ограничений
Появление Object Constraint Language (OCL) было вызвано необходимостью формализации описания условий и ограничений, накладываемых на элементы диаграммы классов UML. Такие условия могут быть сформулированы и на естественном языке, который, однако, не является строгим и формальным и допускает неоднозначные трактовки, вследствие чего не может быть использован при создании UML-моделей. Язык OCL создавался как формальный текстовый язык, дополняющий графические возможности языка UML. В этом смысле OCL является частью UML. При этом средствами языка OCL принципиально невозможно изменить сами элементы модели (классы, атрибуты, отношения). OCL также не является языком программирования, то есть не позволяет создать программу из своих операторов или описать логику выполнения каких-либо действий. Язык OCL представляет собой формальный язык, основанный на выражениях. Любое выражение OCL возвращает некоторое значение.
В Borland MDA язык OCL играет чрезвычайно важную роль, выполняя следующие основные функции:
-
Навигация по элементам модели (классам, атрибутам, ассоциациям);
-
Задание условий и ограничений на элементы модели;
-
Задание выражений для вычисляемых (derived) атрибутов.
Навигация по модели, обеспечиваемая посредством OCL в Borland MDA, позволяет осуществить гибкий и мощный механизм «запросов» к объектному пространству приложения. Понятие объектного пространства охватывает реализацию всех элементов модели во время работы приложения. Такие «OCL-запросы» в принципе способны полностью заменить привычный разработчикам приложений баз данных язык SQL обладая при этом наглядностью, лаконичностью и мощностью. Кроме того, учитывая платформенную независимость OCL, эти запросы являются универсальными и абсолютно не привязаны к конкретной СУБД, используемой в приложении [20].
-
Объектное пространство
Понятие объектного пространства (Object Space) является важнейшим элементом в архитектуре Borland MDA. Без понимания основ работы с объектным пространством многие возможности, предоставляемые этой архитектурой, остаются недоступными.
С одной стороны, объектное пространство можно рассматривать как своеобразный контейнер, в котором во время выполнения приложения размещаются объекты, представляющие собой реализацию элементов UML-модели. С этой точки зрения, объектное пространство, по сути, является экземпляром модели приложения, аналогично тому, как объект является экземпляром класса в ООП. Это означает, что в объектном пространстве «воплощаются» и наполняются конкретным содержанием все сущности и все связи, присутствующие в модели (классы, атрибуты, ассоциации, роли). Каждый объект, содержащийся в объектном пространстве, таким образом, содержит полную информацию о своих свойствах (атрибутах, операциях и т. д.) и об отношениях-связях с другими объектами.
С другой стороны, объектное пространство представляет собой программный буфер (кэш), который накапливает происходящие в системе изменения, возникающие, например, при удалении, изменении или добавлении объектов, в том числе при реализации транзакционных операций. При этом специальные механизмы отслеживают накопление таких изменений и вычисляют «разницу» между состоянием элементов-объектов в памяти и состоянием уровня данных (базы данных). При вызове операции обновления уровня данных (Update Database) механизмы объектного пространства обеспечивают синхронизацию содержимого памяти и базы данных. В этом контексте объектное пространство реализует аналог известных механизмов дотируемого отложенного обновления (Cashed Updates), используемых при работе с СУБД.
Кроме того, объектное пространство содержит специальный механизм отображения данных, называемый «persistence mapper», который служит своеобразным каналом между уровнем данных (реализуемым, например, посредством СУБД) и объектами, содержащимися в Object Space. Таким образом, в архитектуре Borland MDA-приложений объектное пространство занимает центральную часть (рис. 7), реализуя следующие основные функции:
-
Хранение и представление информации о реализации элементов модели во время работы приложения. Обеспечение целостной логической структуры приложения. Обработка внутренних событий системы.
-
Отслеживание происходящих изменений в системе и формирование дельта-информации о накопленных различиях с уровнем данных.
-
Взаимодействие с графическим интерфейсом, предоставление информации о состоянии объектов.
-
Взаимодействие с уровнем данных, синхронизация состояний памяти и базы данных.
Рисунок 2.2 Взаимодействие компонентов Borland MDA
Для обеспечения таких функций в Borland MDA включены специальные классы-носители информации модели, а также классы, реализующие управление элементами объектного пространства, и осуществляющие обработку событий, происходящих в системе.
При запуске MDA-приложения часть объектов загружается с уровня данных в объектное пространство. При этом часть объектов остается не загруженной в память, однако система считает, что они, тем не менее, существуют, поскольку не были удалены во время прошлых сеансов работы. Таким образом, формируется совокупность объектов в памяти и объектов в БД, которая образует так называемое «концептуальное объектное пространство». Если происходит удаление объекта, он, тем не менее, остается в памяти и в БД, пока не будет вызван метод «Update Database». До момента этого вызова такой объект помечается системой как удаленный, но будет продолжать существовать как в памяти, так и в БД, однако, он не будет существовать в концептуальном объектном пространстве, и станет недоступным для использования. Для управления такими ситуациями Borland MDA имеет специальные средства, так называемые машины состояния (State Machines) [28].