AllFusion ERwin Data Modeler API – це простіше, ніж здається, CASE-засоби (моделювання), Програмування, статті

Оновлений програмний інтерфейс додатки (API) продукту AllFusion ERwin Data Modeler (раніше: ERwin) (Версії 4.0 SP2 або пізнішої) набагато простіше у використанні в порівнянні зі своїм попередником. У цій статті даються деякі основні поради про початок роботи з даними API, які можна розглядати як введення в “Довідкове керівництво API”.

Перед читанням даної статті слід переконатися в тому, що встановлені всі компоненти, необхідні для використання AllFusion ERwin Data Modeler API. Встановлюючи AllFusion ERwin Data Modeler версії 4.0 SP2 або пізнішої, потрібно виставити прапорець для установки утиліти ERwin Spy Utility і ERwin API Sample Client. Ці компоненти встановлюються в підкаталог “Samples” основного каталога установки.


Більш проста і узгоджена модель об’єктів робить AllFusion ERwin Data Modeler API версії 4 простіше в експлуатації, ніж ERwin версії 3.5. Нижче перераховані деякі поліпшення.


Парні об’єкти (таблиці, стовпці та індекси) видалені, залишилися тільки категорії, атрибути та ключові групи.
Категорії, атрибути та ключові групи тепер мають логічні та фізичні властивості, подібно доменам в API версії 3.5.
В API версії 3.5 використовувалися властивості, атрибути та ознаки для подання інформації, пов’язаної з об’єктами моделі. API версії 4 використовує тільки властивості.
Проблеми з обробкою багатозначних властивостей були дозволені завдяки новому, більш простому і однаковому методу.


Це тільки декілька основних відмінностей між API версій 3.5 і 4. Однак код для версії 3.5 може бути безперешкодно перенесений у версію 4. Такий перехід до нового API виконується дуже нескладно і код, що виходить у версії 4, буде простіше.


Основна структура API версії 4 настільки ж проста і однорідна, як і у версії 3.5.



  1. Робота ведеться з об’єктами і колекціями об’єктів.
  2. Об’єкти поділяються на батьківські і дочірні. Останні є колекцією об’єктів, для яких кореневими об’єктами (званими контекстом) є батьківські.
  3. Створення об’єктів здійснюється додаванням їх до колекції з одним із батьківських об’єктів в якості контексту.
  4. При роботі з рівнями моделі потрібно розуміти, що об’єкт на одному рівні дає колекцію об’єктів на наступному рівні.

Одним з подібностей API версій 4 і 3.5 є те, що обидва вони засновані на моделі компонентних об’єктів Microsoft (COM) і фактично є COM-серверами. Це означає, що будь-які інструменти, сумісні з COM, можуть бути використані для розробок з використанням API. Наприклад, можна застосовувати такі інструменти як Visual Basic, Visual C + +, Delphi та інші. У прикладах цієї статті використовується VB, щоб зробити подання матеріалу більш простим і зрозумілим. Перед початком робіт з AllFusion ERwin Data Modeler API, використовуючи VB, необхідно додати в поточному проекті посилання на файл SCAPI.dll, який є COM-сервером динамічно під’єднуваних бібліотек (DLL).


Як і в API версії 3.5, можна використовувати версію 4 для розробки додаткових функцій. Додаткові функції активуються за допомогою опції Add-In в меню Tools програми AllFusion ERwin DM і можуть бути використані для роботи з моделями, відкритими в програмі. API можна також використовувати для розробки автономних програм, що працюють з моделями, які відкривають самі програми.


Фактично немає обмежень для розширень та інтеграції, які можна розробляти за допомогою ERwin API.


Модель об’єктів в API версії 4


У цій статті будуть обговорюватися три рівні API версії 4:





рівень застосування;
рівень сесії;
рівень моделі.


Рівень додатків містить чотири об’єкти, з якими вестиметься робота:





об’єкт докладання;
колекція постійних модулів;
об’єкт постійного модуля;
пакет властивостей.

Об’єкт програми є точкою входу – необхідно задати хоча б один об’єкт даного типу. Для рівня програми потрібно використовувати наступний код:


Постійним модулем є або модель ERwin DM, або предметна область моделі ERwin DM. Таким чином, колекція постійних модулів представляє вже відкриті моделі та використовується або для вибору відкритої моделі, або для завдання нової моделі за допомогою додавання нового об’єкт в колекцію. Для того щоб додати новий об’єкт в колекцію можна використовувати наступний код:

“Відкриття нової моделі через додавання об’єкта в колекцію постійних модулів


Проте якщо спробувати додати об’єкт до вже відкритої моделі, то виникне помилка “модель вже відкрита в пам’яті”. Для перевірки того, відкрита модель чи ні, можна використовувати наступну функцію:


Ця функція крім того, що показує, наскільки легко проводити ітерацію по всій колекції, також реалізує потрібну операцію. Ім’я відкритої моделі містить тільки ім’я файлу, а не весь шлях до нього. Це є деякою проблемою, так як ім’я моделі не унікально. Тому потрібно використовувати властивість Locator, яке задається префіксами “erwin :/ /” або “mmart :/ /” перед повним ім’ям. Сама модель має властивість “file name”, яке в принципі можна було б використовувати, але воно вимагає відкриття моделі. Тому використання локатора більш ефективно.


Після завдання постійного об’єкта необхідно почати сесію, в якій потрібно відкрити модель для роботи з нею.


Рівень сесії містить об’єкт Session і колекцію Sessions. Для рівня сесії можна використовувати наступний код:


Якщо метод Open був виконаний успішно, то практично можна починати працювати з моделлю. (Параметр SCD_SL_MO вказує рівень моделі. M1 визначає рівень метамоделі для доступу до даних метамоделі. Для маніпулювання моделями завжди використовується параметр M0).


Щоб працювати з моделлю далі, потрібно ініціювати транзакцію. Це дуже важливий крок. Якщо транзакція не буде розпочато, то при першій же спробі оновити будь-яке з властивостей виникне помилка. Активізація транзакції не буде успішною, якщо сесія закрита або недійсна. Так само потрібно стежити за тим, щоб ідентифікатор транзакції повертався методом Open. Для безпечного і простого поводження з транзакціями краще використовувати такі функції (тут також використовуються деякі особливості VB):


Слід пам’ятати про те, що цілісність моделі після оновлень поверяется під час фіксації змін. Наприклад, якщо створюється взаємозв’язок між батьківського і дочірньої сутностями, не вказавши тип, який є обов’язковим властивістю, то під час фіксації виникне помилка, що повідомляє про те, що завдання типу є обов’язковим, і створення взаємозв’язку буде відхилено.


Продуктивність може постраждати, якщо буде занадто багато оновлень не пройшли фіксацію. Тест на портативному комп’ютері із частотою процесора 500 МГц і ОЗУ 512 МВ показав, що проведення фіксації після 100-200 оновлень є оптимальним. Наявність 5000 і більше оновлень без фіксації може істотно збільшити час прогону програми, в деяких випадках аж до 5-10 разів. Оптимальний вибір проведення фіксації може залежати від конкретного додатка.


Тепер звернемося до рівня моделі, який містить активні об’єкти. Нижче перераховані об’єкти, що належать рівню моделі.





Об’єкт моделі та колекції об’єктів моделі.
Об’єкт властивостей моделі та колекції властивостей об’єктів моделі.
Об’єкт значення властивості моделі та колекції об’єктів значень властивостей моделі.


Доступ до об’єкта здійснюється за допомогою колекції об’єктів моделі, що повертається методом ModelObjects рівня моделі, або через колекцію підмножин, яку створює програмний код, який використовує метод Collect. Наприклад, доступ до предметної області можна отримати наступним чином:


Метод ModelObjects повертає колекцію об’єктів моделі цілком, тоді як ModelObjects.Root дає тільки батьківські або контекстні об’єкти з усієї колекції. Для того щоб створити нову предметну область, потрібно просто додати новий об’єкт до даної колекції:


Додавання нового атрибута до сутності в точності відповідає тій же парадигмі. Наступні функції здійснюють це спільно:


Ця функція полегшує використання API. У функції CreateAttribute новий атрибут сутності створюється простим додаванням його до колекції атрибутів даної сутності.


Доступ до елементів колекції об’єктів здійснюється наступним чином:


Можна помітити, що присвоєння значень виконується для елементів колекції властивостей (наприклад “A.properties.item (NameProperty)”), а не безпосередньо через “A.Name”. Крім того, присвоєння значень властивостям завжди відбувається в масивах (наприклад, A.Properties.Item (NameProperty). Value (0) = Name). Це виходить через те, що всі значення властивостей потенційно багатозначні. Легко перевірити, чи є властивість багатозначним:


Якщо значення не є скаляром, то призначення здійснюється нульового елементу, як було показано вище. Якщо воно – скаляр, то число елементів можна отримати за допомогою властивості Count. Наприклад, наступна функція звертає значення масиву в колекцію:


Для доступу до властивостей використовується метод HasProperty:


Інша цінна можливість API версії 4 – метод FormatAsString. Розглянемо наступний приклад:


в якості альтернативи коду:


В цьому випадку, в результаті будуть повернуті ідентифікатори об’єктів джерел даних. Тоді, для отримання об’єкта потрібно використовувати наступну функцію:


Однак якщо використовується метод FormatAsString, API дає потрібну інтерпретацію навіть тоді, коли значення типу “рядок” і значення властивостей розділені комою.


В кінцевому підсумку, важливо пам’ятати про те, що утиліта ERwin SPY забезпечена інтерфейсом API для того, щоб полегшити дослідження того, як в точності призначені властивості, які властивості існують і які є обов’язковими. Ця утиліта дуже корисна при роботі з API. Для отримання більш детальної інформації рекомендуємо звернутися до “Довідник API” (ERwinAPI.pdf), яке знаходиться в підкаталозі “Docs” основного каталога установки.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*