Интегрирование Rational Software Architect с Rational Data Architect

Объединение модели приложения и модели данных

Управляемая моделями разработка приложений обычно начинается либо с моделирования приложения, либо с моделирования данных. Однако моделирование приложения и моделирование данных тесно взаимосвязаны и дополняют друг друга. IBM разглядела важность интеграции моделирования приложения и моделирования данных и разработала преобразования UML-to-LDM (Unified Modeling Language-to-Logical Data Model) и LDM-to-UML. Эти преобразования интегрируют моделирование приложений с использованием Rational Software Architect (RSA) и моделирование данных с использованием Rational Data Architect (RDA). В данной статье представлен краткий обзор RSA и RDA, рассмотрены общие действия в трех сценариях интеграции RSA-RDA, преобразования UML-to-LDM и LDM-to-UML, а также UML Logical Data Model Profile.

Дэниел Т Чанг, старший инженер-программист, Information Management, Data Tools, IBM

Дэниел Т. Чанг (Daniel T. Chang) - старший инженер-программист в IBM Silicon Valley Lab. В отделе RDA Core работает с 2006 года.



28.05.2008

Управляемый моделями подход начал широко использоваться для разработки программного обеспечения. При такой разработке точкой отсчета обычно служит либо моделирование приложения, либо моделирование данных. Однако они очень похожи друг на друга. Моделирование приложения содержит ключевую бизнес-информацию в виде классов и ассоциаций в форме моделей классов на унифицированном языке моделирования (Unified Modeling Language - UML). Модели классов затем могут использоваться как основа для порождения логических моделей данных при моделировании данных. Моделирование данных, с другой стороны, содержит бизнес-объекты, их взаимоотношения и ограничения в логических моделях данных (Logical Data Model - LDM), которые затем могут использоваться для порождения моделей классов при моделировании приложения.

Правильно построенная LDM может обеспечить единственно адекватное представление ключевой бизнес-информации предприятия. Она может охватить и пережить многие приложения и физические источники данных. Точная, аккуратная и полная семантика в LDM обеспечивает идеальный фундамент для модели классов при решении задачи моделирования приложения на предприятии.

Независимо от того, начать моделирование с приложения или данных, при комплексном подходе к комбинированию этих разных форм моделирования высвобождается мощь управляемой моделями разработки программного обеспечения, потому что:

  • достигается функциональная совместимость модели по всему предприятию и между уровнями корпоративной архитектуры;
  • создаются готовые к повторному использованию информационные модели, полезные для нескольких приложений;
  • разъединяются семантика данных и физическая реализация;
  • обеспечивается разделение задач между разработчиком приложения и разработчиком данных.

IBM, являясь лидером в предоставлении инструментальных средств моделирования приложений, недавно добавила в свой арсенал средства моделирования данных. Пользователи могут моделировать приложения в Rational Software Architecture (RSA) и данные в Rational Data Architect (RDA). IBM, разглядев важность интеграции моделирования приложений и данных в управляемой моделями разработке программного обеспечения, разработала преобразования UML-to-LDM и LDM-to-UML для связи этих инструментальных средств. Преобразование UML-to-LDM является дополнительной функциональной возможностью RSA V7, а преобразование LDM-to-UML является дополнительной функциональной возможностью RDA V7. Подробная информация о процедуре установки каждого из этих продуктов и использовании соответствующего преобразования приведена в интерактивной документации, которая содержит также информацию об отображении объектов.

В данной статье приводится краткий обзор RSA и RDA, а затем в общий чертах рассматриваются три сценария интеграции RSA-RDA. Для сценариев UML-to-LDM (сверху вниз) и LDM-to-UML (снизу вверх) представлены рекомендации, когда организациям нужно рассматривать использование каждого из них. Также в статье обсуждается моделирование приложений в RSA, моделирование данных в RDA и преобразование UML-to-LDM (сверху вниз) и LDM-to-UML (снизу вверх). Кроме того, рассматривается профиль UML Logical Data Model Profile, позволяющий моделировать данные в RSA и расширяющий преобразования UML-to-LDM и LDM-to-UML.

Обратите внимание на то, что хотя преобразования UML-to-LDM и LDM-to-UML являются основой интеграции RSA и RDA, существуют и другие важные аспекты интеграции RSA и RDA, о которых стоит упомянуть:

  • общая совместная установка и командная оболочка для облегчения развертывания и использования;
  • общий репозиторий моделей с использованием Clearcase;
  • общий набор инструментальных средств управляемой моделями разработки (EMF-модель, интегрированная среда преобразований, расширяемость и т.д.).

Обсуждение этих тем выходит за рамки данной статьи.

Rational Software Architect

Rational Software Architect (RSA) - это инструментальная программа моделирования приложений, позволяющая организациям моделировать, анализировать, проектировать и генерировать приложения. Она использует преимущества управляемой моделями разработки с UML для создания хорошо спроектированных приложений и сервисов. RSA:

  • Расширяет открытую и гибкую среду разработки программного обеспечения Eclipse.
  • Использует новейшие достижения технологии моделирования языков, обеспечивая гибкое моделирование разнообразных доменов, включая UML 2, UML-подобное представление для Java и др.
  • Обеспечивает гибкое управление моделями для параллельной разработки и архитектурного рефакторинга; например, можно разделять, комбинировать, сравнивать и объединять модели и фрагменты моделей.
  • Облегчает переход между архитектурой и кодом при помощи преобразований модель-модель и модель-код, а также обратных преобразований.
  • Облегчает переход от проекта к коду для приложений Java™/J2EE™, Web Services, SOA и C/C++.
  • Включает все функциональные возможности IBM Rational Application Developer для интегрированного проектирования и разработки.

Классами в RSA может быть все, что создается, компонуется, инспектируется, тестируется, модифицируется или обрабатывается в приложениях. На рисунке 1 показано несколько примеров классов и их ассоциации - Invoice, InvoiceItem, ProductInvoice и ServiceInvoice из примера RSA-проекта под названием Invoice. Обратите внимание на три различных типа ассоциаций: композицию (invoice - item), объединение (main - associate) и простую ассоциацию (product - service). Эти типы ассоциации будут рассмотрены ниже.

Рисунок 1. Пример модели классов в проекте RSA Invoice
Рисунок 1. Пример модели классов в проекте RSA Invoice

Rational Data Architect

Rational Data Architect (RDA) это инструментальная программа моделирования корпоративных данных и проектирования интеграции. Она упрощает моделирование данных и проектирование интеграции, позволяя разработчикам обнаружить, смоделировать, визуализировать и связать разнообразные и распределенные объекты данных. Используя RDA, можно:

  • Создать логические и физические модели данных.
  • Сравнить и синхронизировать структуры и элементы двух моделей данных.
  • Проанализировать модели данных на корректность и соответствие корпоративным стандартам.
  • Найти, исследовать и визуализировать структуру источников данных.
  • Использовать отображение для обнаружения потенциальных взаимосвязей и идентификации взаимосвязей между несовместимыми источниками данных.

На рисунке 2 показан пример LDM из примера RDA-проекта под названием Invoice. Обратите внимание на три типа взаимосвязей: отождествление (identifying) (item – invoice), не отождествление (associate - main) и "многие ко многим" (many-to-many) (service - product). Также обратите внимание на то, что для обобщения имеет место наследование ключей, а для взаимосвязей отождествления и не отождествления - миграция ключей. Эта тема рассматривается ниже.

Рисунок 2. Пример логической модели данных в проекте RDA Invoice
Рисунок 2. Пример логической модели данных в проекте RDA Invoice

Логические модели данных (Logical Data Model - LDM) часто не учитывались в цикле разработки программного обеспечения, но они становятся все более важными по многим причинам. LDM обеспечивает представление логических объектов данных бизнес-деятельности или предприятия без деталей реализации; она отделяет семантику данных от реализации и особенно полезна при работе с современными, все более сложными и гетерогенными информационными средами. Другие логические или физические модели, например, модели сервисов, модели сообщений, модели классов и модели хранилищ данных могут быть визуализированы в общей LDM. В таких современных инструментариях управляемой моделями разработки как Rational Data Architect и Rational Software Architect пользователь может даже сгенерировать нисходящие модели и физические реализации на основе LDM. Без преувеличения можно сказать, что LDM является информационным центром организации. LDM позволяет реализовать корпоративное представление данных, которое, в свою очередь, помогает уменьшить избыточность данных, улучшить их качество и ускорить интеграцию.

Сценарии интеграции

Существуют три исходных сценария интеграции моделирования приложения и моделирования данных: сверху вниз, снизу вверх и встречный (meet-in-the-middle). В следующих разделах более подробно рассматривается каждый из этих сценариев. Предполагается участие двух главных IT-ролей - Application Modeler (разработчик приложения) выполняет моделирование приложения, а Data Modeler (разработчик данных) занимается моделированием данных.

Сверху вниз: От моделирования приложения к моделированию данных

В сценарии "сверху вниз" элементы моделирования классов (классы, свойства и ассоциации) в RSA преобразуются в элементы моделирования LDM (логические объекты, атрибуты и взаимосвязи) для использования в RDA.

В данном сценарии выполняются следующие действия:

  1. Application Modeler моделирует приложения в RSA. Бизнес-данные или данные приложения заключаются в модели классов.
  2. Application Modeler преобразовывает часть (или всю полностью) модели классов в LDM при помощи преобразования UML-to-LDM.
  3. Data Modeler обращается к LDM и импортирует ее в RDA.
  4. Data Modeler преобразовывает LDM в физическую модель данных (Physical Data Model - PDM), а затем генерирует схему базы данных при помощи RDA.

На следующей схеме показано взаимодействие ролей Application Modeler и Data Modeler в сценарии "сверху вниз".

Рисунок 3. Сценарий интеграции "сверху вниз": от моделирования приложения к моделированию данных
Рисунок 3. Сценарий интеграции

Мы рекомендуемы организациям рассмотреть использование сценария "сверху вниз" при наличии комбинации следующих условий:

  • Моделирование приложения является первичным для проекта.
  • Приложения используют общие бизнес-модули или хранилища данных.
  • Приложения сконцентрированы вокруг объектов и имеют ограниченные требования к управлению данными, отличные от персистенции.
  • LDM не доступна.
  • Физическая схема базы данных отсутствует.

Однако пользователи иногда выбирают сценарий "сверху вниз" по неправильным причинам. Ниже перечислены (в кавычках) некоторые "плохие" причины принятия решения использовать сценарий "сверху вниз"; для каждого них приведено возражение против выбора такого сценария:

  • "Мы никогда не выполняли LDM раньше". Всегда что-то делается в первый раз. Если ваша организация в прошлом избегала LDM, чем раньше вы начнете работать с LDM, тем состоятельнее организация будет выглядеть в долгосрочной перспективе.
  • "У нас нет опыта работы с LDM". Хороший разработчик данных оправдывает инвестицию, поэтому вам следует нанять кого-нибудь с опытом работы с LDM или подготовить имеющегося сотрудника.
  • "Нам нужно только сохранять данные для использования в данном приложении". Большинство корпоративных приложений должны совместно использовать данные с другими корпоративными приложениями. LDM уменьшит общую стоимость владения (Total Cost of Ownership).

Наконец, доводы против подхода "сверху вниз", которые нужно учитывать:

  • Модели данных могут стать тесно связанными с конкретными приложениями.
  • Модели классов могут быть не готовы для повторного использования в LDM из-за денормализации и сконцентрированного вокруг объектов моделирования приложения.

Снизу вверх: От моделирования данных к моделированию приложения

В сценарии "снизу вверх" элементы моделирования LDM (логические объекты, атрибуты и взаимосвязи) преобразуются в элементы моделирования классов (классы, свойства и ассоциации) для использования в RSA. С корпоративной точки зрения в долгосрочной перспективе предпочтительнее применить подход "снизу вверх", чем "сверху вниз", из-за ограничений подхода "сверху вниз" и многих преимуществ LDM, упомянутых в предыдущих разделах. Кроме того, подход "снизу вверх" позволяет разделить задачи - Data Modeler концентрируется на разработке корпоративной терминологии и моделей данных; Application Modeler концентрируется на моделировании приложений.

В данном сценарии выполняются следующие действия:

  1. Data Modeler моделирует данные в LDM в RDA. Если имеется схема базы данных, но нет физической или логической модели, Data Modeler генерирует PDM из существующей схемы и преобразовывает PDM в LDM.
  2. Data Modeler преобразует часть (или всю полностью) LDM в модель классов при помощи преобразования LDM-to-UML.
  3. Application Modeler обращается к модели классов и импортирует ее в RSA.

На следующей схеме показано взаимодействие между Application Modeler и Data Modeler в сценарии "снизу вверх".

Рисунок 4. Сценарий интеграции "снизу вверх": от моделирования данных к моделированию приложения
Рисунок 4. Сценарий интеграции

Мы рекомендуемы организациям рассмотреть использование сценария "сверху вниз" при наличии комбинации следующих условий:

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

Наконец, подход "снизу вверх" тоже имеет контраргументы:

  • Во время преобразования из LDM в модель классов могут теряться некоторые семантики, поскольку семантика данных в LDM богаче (например, первичные ключи), чем семантика моделей классов.
  • Поскольку LDM стремится быть более полной, чем модели классов, втискивание LDM в модели классов без соответствующего взаимодействия может ошеломить разработчиков приложения своей детальностью. Если разработчики приложения не понимают LDM, они могут закончить изобретением колеса и определить логические объекты и атрибуты, уже имеющиеся в LDM. То есть, необходимо соответствующее обучение и взаимодействие между ролями Data Modeler и Application Modeler. В идеальном случае разработчиков приложения необходимо обучить пониманию и использованию логических моделей данных.

Встречный сценарий

В предыдущих разделах рассматривались сценарии "сверху вниз" и "снизу вверх", которые в основном относятся к новой разработке. Однако единственной константой в разработке программного обеспечения является изменение. Моделирование приложения и моделирование данных редко бывают единовременным процессом. Чтобы избежать морального старения, этот процесс должен быть итеративным и быстро удовлетворять бизнес-требованиям. Следовательно, инструментальные средства моделирования приложений и моделирования данных должны поддерживать возможность обновления моделей. Например, изменения в модели классов должны быть обновлены и отражены в LDM либо при помощи автоматизированных (для простых изменений), либо при помощи ручных (при необходимости сложной эвристики) методов для конвергенции моделей; то же самое касается и отражения изменений LDM в модели классов.

В реальной жизни управление синхронизацией и изменениями моделей классов и LDM является непростой задачей, поскольку для этого используются разные средства, и часто эта задача выполняется двумя различными ролями - Application Modeler и Data Modeler. Тем не менее, при тщательном планировании, отличном взаимодействии и четком управлении изменениями можно эффективно использовать функциональные возможности инструментария и достичь глобальной управляемости данных.

Во встречном сценарии имеются два варианта, зависящие от того, что вы хотите обновить - модели классов или LDM:

  1. Как только модели классов преобразовываются в LDM и используются в RDA, Application Modeler выполняют определенные изменения в моделях классов, например, добавляют новые свойства. Мы хотим обновить LDM в RDA для отображения обновленных моделей классов. Этот вариант является расширением сценария "сверху вниз", в который добавлена синхронизация существующих LDM в RDA с новой или измененной информацией.

Для первого варианта использования выполняются следующие действия:

  1. Data Modeler использует LDM версии 1 в RDA, который был предварительно преобразован из модели классов версии 1 в RSA.
  2. Application Modeler изменяет модель классов версии 1 в RSA, а затем преобразовывает обновленную модель классов (версия 2) как LDM версии 1+.
  3. Data Modeler получает и импортирует LDM версии 1+ в RDA.
  4. Data Modeler сравнивает и объединяет LDM версии 1+ и версии 1 в LDM версии 2 в RDA.

На следующей схеме показано взаимодействие между Application Modeler и Data Modeler в первом варианте использования.

Рисунок 5. Встречный сценарий - от моделирования приложения к моделированию данных
Рисунок 5. Встречный сценарий - от моделирования приложения к моделированию данных
  1. После преобразования моделей LDM в модели классов и использования RSA Data Modeler выполняют определенные изменения в моделях LDM, например, добавляют новые столбцы. Вы должны обновить модели классов в RSA для отражения измененных моделей LDM. Этот вариант использования очень похож на сценарий "снизу вверх" с добавлением синхронизации существующих моделей классов в RSA с новой или измененной информацией.

Для второго варианта использования выполняются следующие действия:

  1. Application Modeler использует модель классов версии 1 в RSA, которая была предварительно преобразована из LDM версии 1 в RDA.
  2. Data Modeler изменяет LDM версии 1 в RDA, а затем преобразовывает измененную LDM (версии 2) как модель классов версии 1+.
  3. Application Modeler получает и импортирует модель классов версии 1+ в RSA.
  4. Application Modeler сравнивает и объединяет модель классов версии 1+ и версии 1 в модель классов версии 2 в RSA.

На следующей схеме показано взаимодействие между Application Modeler и Data Modeler во втором варианте использования.

Рисунок 6. Встречный сценарий - от моделирования данных к моделированию приложения
Рисунок 6. Встречный сценарий - от моделирования данных к моделированию приложения

Преобразования моделей

Преобразования моделей являются основой интеграции моделирования приложения и моделирования данных. В рассмотренном выше сценарии "сверху вниз" модели классов преобразовываются в логические модели данных при помощи преобразования UML-to-LDM; в сценарии "снизу вверх" логические модели данных преобразовываются в модели классов при помощи преобразования LDM-to-UML.

Модель классов UML

Модель классов определяет:

  • Модель и пакеты: они служат структурными компонентами и пространствами имен (namespaces) для других элементов модели. Пакет может содержать пакеты, схемы, классы, ассоциации, классы ассоциаций и типы данных.
  • Классы: они представляют концепции внутри моделируемой системы. Экземпляры одного и того же класса имеют общие характеристики. Класс имеет:
    • Свойства: описания характеристик класса. Свойство помимо прочего имеет тип, определяющий тип значения, которое оно может иметь.
    • Обобщения (generalizations): класс может иметь обобщения, например, взаимосвязи таксономий, между ним и более общими классами. Класс полностью согласован с более общим классом и содержит дополнительные свойства.
  • Ассоциации: они представляют семантические взаимосвязи между двумя классами, экземпляры которых вовлечены в соединения. Кроме простой формы ассоциации существуют две дополнительные формы:
    • Агрегация (aggregation): форма ассоциации, специфицирующая взаимосвязь целое-часть между совокупностью (целое) и составной частью.
    • Композиция: форма агрегации с сильной принадлежностью частей объединению (целому) и синхронным временем жизни частей с совокупностью. Часть может принадлежать только одной совокупности.
  • Классы ассоциации: класс ассоциации - это ассоциация, являющаяся также классом. Класс ассоциации соединяет два класса и имеет свойства.
  • Типы данных: тип данных - это дескриптор набора значений. К типам данных относятся:
    • Предопределенные примитивные типы: Boolean, Number, String, UnlimitedNatural.
    • Определенные пользователем типы данных: примитивные типы или перечисления.

Пример модели класса приведен на рисунке 1 выше.

Логическая модель данных RDA

Логическая модель данных определяет:

  • Пакеты: они служат структурными компонентами для других элементов модели. Пакет может содержать пакеты, схемы, логические объекты и домены.
  • Логические объекты (entities): представляют концепции, события, субъекты, месторасположения или другие понятия, информация о которых сохраняется. Экземпляры одного и того же логического объекта имеют общие характеристики. Логические объекты могут быть либо независимыми, либо зависимыми. Логический объект, экземпляры которого нельзя уникально идентифицировать без определения его взаимосвязи с другим логическим объектом или объектами, является зависимым логическим объектом; в противном случае - это независимый логический объект. Логический объект имеет:
    • Атрибуты: описания характеристик логического объекта. Атрибут имеет, среди прочего, тип, определяющий тип значений, которые он может иметь.
    • Первичный ключ: атрибут или атрибуты, однозначно идентифицирующие экземпляр логического объекта.
    • Обобщения: логический объект может иметь обобщения, т.е. взаимосвязи таксономий, между ним и более общими логическими объектами. Логический объект полностью согласован с более общим логически объектом и содержит дополнительные атрибуты.
  • Взаимосвязи: представляют соединения, связи или ассоциации между двумя логическими объектами. Имеется три типа взаимосвязей:
    • Идентифицирующая взаимосвязь: взаимосвязь, посредством которой экземпляр дочернего логического объекта идентифицируется через свою ассоциацию с родительским логическим объектом. Атрибуты первичного ключа родительского логического объекта становятся атрибутами первичного ключа потомка.
    • Не идентифицирующая взаимосвязь: взаимосвязь, посредством которой экземпляр дочернего логического объекта не идентифицируется через свою ассоциацию с родительским логическим объектом. Атрибуты первичного ключа родительского логического объекта становятся не ключевыми атрибутами потомка.
    • Взаимосвязь "многие ко многим": ассоциация между двумя логическими объектами, в которых каждый экземпляр первого логического объекта ассоциируется с ноль, одним или несколькими экземплярами второго логического объекта, а каждый экземпляр второго логического объекта ассоциируется с ноль, одним или несколькими экземплярами первого логического объекта.
  • Типы данных: тип данных - это дескриптор набора значений. К типам данных относятся:
    • Предопределенные типы данных: BINARY, BLOB, BOOLEAN, CHAR, CLOB, DATALINK, DATE, DECIMAL, DOUBLE, FLOAT, INTEGER, INTERVAL, LONG, ROWID, SHORT, TIME, TIMESTAMP, VARBINARY, VARCHAR, XML.
    • Определенные пользователем типы данных: атомарные домены (atomic domains).

Пример логической модели данных приведен на рисунке 2 выше.

Сверху вниз: От модели классов к логической модели данных

В приведенном выше обсуждении можно заметить, что модель классов UML и логическая модель данных RDA очень хорошо соответствуют друг другу по конструкциям и семантикам моделирования. Как результат, преобразование модели классов в логическую модель данных обычно является простым и не приводит к потере информации.

В таблице 1 показано отображение из модели классов (источник) в логическую модель данных (назначение). В таблице стоит отметить:

  • Класс не имеет первичного ключа; он имеет скрытый OID (идентификатор объекта). Он преобразовывается в свернутый ключ (surrogate key).
  • Простая ассоциация преобразовывается в не идентифицирующую взаимосвязь, если ассоциация заканчивается кратностью либо 0.1, либо 1; в противном случае она преобразовывается во взаимосвязь "многие ко многим".
  • Свойство может иметь в качестве типа ссылку на класс, имеющую идентичную агрегации семантику. Следовательно, ссылка на класс преобразовывается в не идентифицирующую взаимосвязь.
  • Класс ассоциации представляет собой концепцию, которая не существует в логической модели данных. Он преобразовывается в логический объект и две взаимосвязи для сохранения семантики класса ассоциации.
Таблица 1. Отображение UML-to-LDM
Таблица 1. Отображение UML-to-LDM

На рисунке 7 показана целевая логическая модель данных, сгенерированная преобразованием UML-to-LDM, которое использует пример модели класса, изображенной на рисунке 1. Сравнивая исходную и целевую модели, обратите, пожалуйста, внимание на следующее:

  • Свернутый ключ (например, Invoice ID для Invoice) генерируется для каждого логического объекта.
  • Для обобщения выполняется наследование ключа (например, Invoice ID из Invoice to ProductInvoice).
  • Для композиции выполняется миграция ключа (например, Invoice Id to invoiceInvoice Id из Invoice to InvoiceItem).
  • Для агрегации выполняется миграция ключа (например, Invoice Id to mainInvoiceID из Invoice to Invoice).
  • Для миграции ключа по умолчанию имя атрибута дочернего внешнего ключа генерируется путем добавления в качестве префикса названия роли предка к имени атрибута родительского первичного ключа.
Рисунок 7. Логическая модель данных, сгенерированная преобразованием UML-to-LDM
Рисунок 7. Логическая модель данных, сгенерированная преобразованием UML-to-LDM

UML Logical Data Model Profile

Не все классы, определенные во время моделирования приложения, обязательно имеют отношение к моделированию данных или имеют персистентные данные; аналогично, не все примитивные типы или перечисления обязательно соответствуют типам данных, необходимым для моделирования данных или для персистентных данных. UML Logical Data Model Profile (профиль логической модели данных UML) можно использовать для:

  • Разрешения пользователю управлять тем, какие классы, примитивные типы или перечисления преобразовывать в логическую модель данных.
  • Указания концепций, важных для моделирования логических данных, но отсутствующих в UML, в том числе:
    • Атрибут (ы) первичного ключа.
    • Определенные пользователем типы данных: более подробная информация, чем та, которую можно указать с примитивными типами или перечислениями.
    • Ссылочная целостность: например, правило удаления предка.

По существу, UML Logical Data Model Profile позволяет пользователю выполнить моделирование логических данных, используя UML в RSA.

В таблице 2 показаны стереотипы и атрибуты, предоставляемые Logical Data Model Profile. Обратите, пожалуйста, внимание:

  • Перечисления и примитивные типы могут быть стереотипированы как Domain. Если это так, можно указать дополнительную информацию (например, базовый тип).
  • Классы могут быть стереотипированы как Entity. По умолчанию они являются персистентными и не используют свернутый ключ.
  • Свойства всегда стереотипированы как Attribute. По умолчанию они не требуются.
  • Свойства могут быть стереотипированы как PrimaryKey.
  • Ассоциации и классы ассоциаций всегда стереотипируются как Relationship. Если это так, можно указать имена атрибутов внешнего ключа (в форме пар имени атрибута первичного ключа, имени атрибута внешнего ключа) и правило удаления предка (NONE / RESTRICT / CASCADE / SET NULL / SET DEFAUL). В будущем также можно будет указать правило удаления потомка.
Таблица 2. UML Logical Data Model Profile
Таблица 2. UML Logical Data Model Profile

В таблице 3 приведено отображение модели класса (источник) в логическую модель данных (назначение) при применении Logical Data Model Profile к модели класса. Стоит отметить, что:

  • Только классы, стереотипированные как Entity, преобразовываются в логические объекты. По умолчанию они являются персистентными и не используют свернутый ключ.
  • Свойства, стереотипированные как PrimaryKey, преобразовываются в атрибуты первичного ключа; в этом случае необходимы сгенерированные атрибуты.
  • Для ассоциаций и классов ассоциаций, если указаны имена атрибутов внешнего ключа и правило удаления предка, они используются для сгенерированной взаимосвязи. В будущем будет также использоваться правило удаления потомка при его указании.
  • Только примитивные типы/перечисления, стереотипированные как Domain, преобразовываются в атомарные домены.
Таблица 3. Отображение UML-to-LDM с Logical Data Model Profile
Таблица 3. Отображение UML-to-LDM с Logical Data Model Profile

На рисунке 8 показан пример модели классов с применением Logical Data Model Profile. Обратите, пожалуйста, внимание:

  • Все примитивные типы стереотипированы как Domain.
  • Все классы стереотипированы как Entity.
  • Атрибуты ID Invoice и InvoiceItem стереотипированы как PrimaryKey.
Рисунок 8. Пример модели классов с Logical Data Model Profile
Рисунок 8. Пример модели классов с Logical Data Model Profile

На рисунке 9 показана целевая логическая модель данных, сгенерированная преобразованием UML-to-LDM. Пример использованной в данном преобразовании исходной модели классов приведен на рисунке 8. Сравнивая исходную и целевую модели, обратите, пожалуйста, внимание:

  • Свернутые ключи не генерируются. Вместо них генерируются атрибуты первичного ключа (ID of Invoice и ID of InvoiceItem).
  • Для обобщения выполняется наследование ключа (ID из Invoice to ProductInvoice).
  • Для композиции выполняется миграция ключа (Invoice Id to ivoiceID из Invoice to InvoiceItem).
  • Для агрегации выполняется миграция ключа (ID to mainID из Invoice to Invoice).
  • Для миграции ключа по умолчанию имя атрибута дочернего внешнего ключа генерируется путем добавления в качестве префикса названия роли предка к имени атрибута родительского первичного ключа.
Рисунок 9. Логическая модель данных, сгенерированная преобразованием UML-to-LDM с применением Logical Data Model Profile
Рисунок 9. Логическая модель данных, сгенерированная преобразованием UML-to-LDM с применением Logical Data Model Profile

Снизу вверх: из логической модели данных в модель классов

Аналогично преобразованию "сверху вниз", преобразование логической модели данных в модель классов обычно является простым и не приводит к потерям информации. В таблице 4 показано отображение логической модели данных (источник) в модель классов (назначение).

Таблица 4. Отображение LDM-to-UML
Таблица 4. Отображение LDM-to-UML

На рисунке 10 показана целевая модель классов, сгенерированная преобразованием LDM-to-UML. Пример используемой в данном преобразовании исходной логической модели данных приведен на рисунке 2. Сравнивая исходную и целевую модели, обратите, пожалуйста, внимание:

  • Информация о первичном ключе (ID of Invoice) теряется в модели классов, поскольку модель классов UML не поддерживает концепцию первичных ключей.
  • Атрибуты внешнего ключа (invoiceID of InvoiceItem) не преобразовываются в модель классов, поскольку они генерируются миграцией ключа в логическую модель данных и не свойственны модели.
Рисунок 10. Модель классов, сгенерированная преобразованием LDM-to-UML
Рисунок 10. Модель классов, сгенерированная преобразованием LDM-to-UML

Для сохранения концепций моделирования логических данных и информации в целевой модели классов к целевой модели классов можно применить Logical Data Model Profile при преобразовании LDM-to-UML. В таблице 5 показано отображение логической модели данных (источник) в модель классов (назначение) с применением Logical Data Model Profile. Обратите, пожалуйста, внимание:

  • Логические объекты преобразовываются в классы, стереотипированные как Entity.
  • Атрибуты первичного ключа преобразовываются в свойства, стереотипированные как PrimaryKey.
  • Атомарные домены преобразовываются в примитивные типы и перечисления, стереотипированные как Domain.
Таблиц 5. Отображение LDM-to-UML с Logical Data Model Profile
Таблиц 5. Отображение LDM-to-UML с Logical Data Model Profile

На рисунке 11 показана целевая модель классов, сгенерированная преобразованием LDM-to-UML, с применением Logical Data Model Profile к целевой модели классов. Пример исходной логической модели данных, используемой в данной преобразовании, приведен на рисунке 2. Сравнивая исходную и целевую модели, обратите, пожалуйста, внимание:

  • Информация о первичном ключе (ID of Invoice) сохраняется в модели классов.
  • Атрибуты внешнего ключа (invoiceID of InvoiceItem) не преобразовываются в модель классов, поскольку они генерируются миграцией ключа в логической модели данных и не свойственны модели.
Рисунок 11. UML-модель, сгенерированная преобразованием LDM-to-UML с Logical Data Model Profile
Рисунок 11. UML-модель, сгенерированная преобразованием LDM-to-UML с Logical Data Model Profile

Заключение

В данной статье представлен общий обзор RSA и RDA и их интеграции. Были рассмотрены три сценария интеграции и критерии выбора сценария "сверху вниз" или "снизу вверх". Для того чтобы создать правильно сформированные модели приложения и модели данных, недостаточно просто знать, как использовать инструментальные средства. Не менее важно знать причины выбора определенного сценария, определить надежную и повторяемую процедуру управления изменениями, создать стратегию, использующую преимущества синергии моделирования приложений и моделирования данных. Успешная интеграция моделирования приложений и моделирования данных может потребовать также организационных и культурных изменений. Надеемся, что данная статья поможет вам начать интегрированное моделирование приложений и данных.

В статье также подробно рассматриваются преобразования UML-to-LDM и LDM-to-UML, а также UML Logical Data Model Profile. Вообще, полезно применить логическую модель данных к модели классов независимо от того, служит ли модель классов источником, или генерируется как цель. В формальной ситуации это позволяет пользователю управлять тем, какие классы, примитивные типы или перечисления преобразовывать в логическую модель данных, и указать концепции и информацию, важные для моделирования логических данных, но отсутствующие в UML. В последнем случае преобразование делается обратимым, поскольку главные концепции моделирования логических данных и информации сохраняются в сгенерированной модели классов.

Как показано на рисунке 12, моделирование логических данных является основой интеграции моделирования данных. В данной статье вы увидели, как можно интегрировать моделирование приложений в RSA с моделированием логических данных в RDA. Интеграция между моделированием логических данных и моделированием реляционных данных является стандартной функциональной возможностью RDA. Интеграция между бизнес-моделированием в WBM и моделированием логических данных в RDA, также как интеграция между моделированием логических данных и моделированием XML-данных в RDA, уже работают и будут рассмотрены в следующей статье developerWorks.

Рисунок 12. Моделирование логических данных как основа интеграции моделирования данных
Рисунок 12. Моделирование логических данных как основа интеграции моделирования данных

Благодарности

Спасибо Дер Пингу Чоу (Der Ping Chou), Дэйвору Горнику (Davor Gornik), Гэрри Робинсону (Gary Robinson) и Хонг-Ли Ю (Hong-Lee Yu) за предварительное ознакомление и комментарии к данной статье. Спасибо Андреа Драздосу (Andreas Drasdos) (GAD) за ценную информацию о преобразовании UML-to-LDM и UML Logical Data Model Profile.


Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management, Rational
ArticleID=310640
ArticleTitle=Интегрирование Rational Software Architect с Rational Data Architect
publish-date=05282008