Bold – інструмент реалізації MDA в Delphi. Частина 3. Borland MDA і модель програми, Комерція, Різне, статті

Частина 2


Зміст



Borland MDA


У першій частині статті було дано огляд MDA-архітектури, у другій ми ознайомилися з практичною реалізацією цієї технології на прикладі створення програми з використанням програмного інструментарію Bold for Delphi. Перш ніж рухатися далі, доцільно повідомити деяку додаткову інформацію про поточний стан та особливості реалізації технології MDA в Borland Delphi.


Як уже говорилося, компанія BoldSoft була придбана фірмою Borland і останнім часом назва продукту Bold for Delphi все частіше замінюється на Borland MDA. Більш того, попередні версії Bold for Delphi в даний час недоступні для розробників, і тому єдиним продуктом реалізації MDA в Delphi зараз є Borland Delphi 7 Studio Architect (існує також можливість поновлення версії Borland Delphi 7 Studio Enterprise). Всі поточні і наступні поновлення Borland MDA здійснює Borland (недавно вийшла остання оновлена ​​версія Bold for Delphi 4.0.0.21, доступна на Web-сайті компанії Borland зареєстрованим користувачам).


З великою часткою ймовірності можна стверджувати, що найближчим часом технологія Bold буде повністю інтегрована в нові версії продуктів Borland. З урахуванням придбання фірмою Borland компанії TogetherSoft можна прогнозувати інтеграцію продуктів цих компаній, що повинно привести до вельми вражаючих результатів.


Однак необхідно відзначити, що на шляху практичного оволодіння технологією Borland MDA розробник може зіткнутися з деякими труднощами.


По-перше, Borland MDA – це складна і об’ємна програмна система. У простому прикладі, розглянутому в попередній частині статті, з усього арсеналу її можливостей був використаний лише дуже незначний відсоток. Насправді Borland MDA включає близько 1700 нових класів, що містять тисячі атрибутів і методів. Досить сказати, що вбудована довідка по продукту налічує близько 10 тис. статей.


По-друге, в даний час технічної інформації про Borland MDA явно недостатньо. Незважаючи на великий обсяг вбудованої довідки, вона, на жаль, дуже лаконічна. Практично єдиним корисним джерелом конкретної інформації про продукт в даний час є Інтернет-конференції на новинному сервері Borland (), де розміщені дві основні групи новин по Borland MDA: borland.public.delphi.modeldrivenarchitecture.general і borland.public.delphi.modeldrivenarchitecture.thirdpary. Крім того, корисна колекція посилань по даній темі зібрана на сайті www.boldbox.com. Залишається сподіватися, що надалі ситуація зміниться на краще.


І нарешті, по-третє, Borland MDA – це якісно нова технологія розробки, можна сказати, цілий новий світ, і перехід на неї можливий лише при перебудові світогляду розробника. Тут все незвично, якщо відштовхуватися від традиційних методів і засобів. Тому на практиці цілком можлива досить парадоксальна ситуація: чим менше у розробника досвіду створення додатків баз даних, тим легше йому буде освоїтися в Borland MDA.


Далі в цій і в наступних частинах статті будуть розглянуті (з можливим ступенем детальності, обмеженої рамками журнальних публікацій) основи Borland MDA. І почнемо, в повній відповідності з назвою технології – Model Driven Architecture, з моделі програми.


Роль моделі в Bold


Як уже говорилося, модель програми є основою MDA-технології. Вона містить склад, структуру та елементи поведінки розробляється. З позиції Bold модель має наступне функціональне призначення:



У Bold, таким чином, відсутнє чітке розділення між PIM (Platform Independent Model) – і PSM (Platform Specific Model)-моделями MDA (див. першу частину статті), а вся необхідна інформація міститься в одній загальній моделі. Функції PSM-моделі в основному виконує набір тег-параметрів (tagged values), які будуть описані нижче. Крім того, такі функції можуть виконувати і деякі компоненти Bold, що є адаптерами СУБД (питань взаємодії Borland MDA і СУБД буде присвячена окрема частина даної статті).


Bold використовує модель для реалізації наступних основних функцій:


1. Генерація коду. Під генерацією коду розуміється автоматичне створення модулів описів (*. Inc-файлів) і функціональних модулів (*. Pas-файлів) на мові Object Pascal, що містять повну реалізацію класів моделі програми. Строго кажучи, сам по собі Bold не потребує генерації коду. Як ми вже бачили на прикладі простого додатка і побачимо надалі, можна створювати досить серйозні програми, взагалі не використовуючи генерацію коду. Проте в деяких випадках вона буває необхідною. Загальна стратегія тут виглядає приблизно так: якщо підтримуваних Bold можливостей мови OCL недостатньо для реалізації, наприклад, бажаних методів або обчислюваних атрибутів на бізнес-рівні, то розробник вправі опуститися на рівень програмного коду. Крім того, генерація коду необхідна, якщо класи моделі містять операції. Генерацію коду можна зробити з вбудованого редактора моделі (Model Editor) на етапі розробки програми. Крім генерації коду, Bold забезпечує і можливість генерації інтерфейсів, необхідних для функціонування розподілених DCOM-додатків.


2. Генерація схеми бази даних. Структура бази даних (тобто набір описів таблиць, полів, індексів і ключів) може бути згенерована автоматично як з вбудованого редактора моделі на етапі розробки, так і програмно під час виконання програми. Bold також підтримує синхронізацію структури бази даних зі змінною в часі моделлю додатки (Model Evolution – еволюція моделі), при цьому зберігається вже наявна в БД інформація. Така можливість у Bold носить спеціальну назву – еволюція бази даних (DataBase Evolution). Надалі ці питання ми розглянемо докладніше. Необхідно мати на увазі, що між складом класів моделі і складом таблиць генерується бази даних немає взаємно-однозначної відповідності. По-перше, Bold використовує ряд таблиць БД для власних потреб і створює їх автоматично. По-друге, не всі класи моделі вимагають збереження інформації об’єктів в БД (persistent class), а можуть бути транзієнтної (transient) класами, крім того, навіть в persistent-класах моделі часто присутні обчислювані (Derived) атрибути, які не зберігаються в базі даних. І по-третє, в ряді випадків принципово неможливо в реляційної БД реалізувати деякі види відносин (див. наступний розділ).


3. Інтерпретація моделі під час виконання для управління поведінкою програми. Вся інформація про моделі зберігається в компоненті TBoldModel і на етапі виконання програми використовується для управління об’єктним простором, для контролю його цілісності, а також для управління взаємодією бізнес-рівня з рівнем даних і графічним інтерфейсом. Об’єктне простір (Object Spase) в Borland MDA є екземпляром моделі за аналогією з тим, як об’єкт є екземпляром класу в ООП. Управління кожним об’єктним простором забезпечується компонентом TBoldSystemHandle. Інформацію про типи цей компонент отримує з компонента TBoldSystemTypeInfoHandle.


В основі створення моделі програми лежить уніфікована мова моделювання (UML), а більш конкретно – діаграма класів. Розуміння основ створення діаграми класів є необхідною умовою практичного застосування MDA. Для повного розуміння діаграм класів необхідне знання UML, систематичний опис якого виходить за рамки даної публікації, проте, з урахуванням тієї обставини, що для розуміння основ роботи з Bold цілком достатньо початкових відомостей про діаграмі класів, нижче дуже коротко описані базові елементи і правила, на основі яких можна буде в подальшому формувати моделі додатків.


Основи створення діаграми класів


До складу стандарту UML входить вісім типів основних діаграм, вичерпним чином описують моделируемое додаток. Bold використовує тільки один з них – діаграму класів (class diagram).


Діаграма класів є основним джерелом переносних незалежної інформації (PIM) для формування моделі програми в Borland MDA. Вона займає центральне місце в об’єктно-орієнтованому аналізі і проектуванні (ООАП) програмних систем. Діаграма класів описує статичну структуру системи, тобто склад елементів (класів), склад їх атрибутів і операцій, а також зв’язки між класами (відносини). У ній не міститься інформація про розвиток системи в часі.


В основі діаграми класів лежить поняття класу. Не заглиблюючись зараз у деталі, будемо вважати, що поняття класу знайоме розробникам, що використовують методологію об’єктно-орієнтованого програмування. Отже, клас зображується в UML-моделі у вигляді прямокутника, розділеного на дві або три частини (рис. 1). У верхній частині відображається ім’я класу – це обов’язковий параметр. У другій зверху частини відображаються атрибути класу, можливо – із зазначенням їх типу і значення за замовчуванням. У нижній частині класу відображаються назви операцій і, можливо, списки аргументів і тип повертається результату. Атрибутів і операцій у класу може бути кілька. З точки зору програміста атрибути та операції аналогічні відповідно властивостям і методам в об’єктно-орієнтованому програмуванні (ООП). Клас, який не може мати жодного об’єкта (примірника), є абстрактним. В цьому випадку його назва відображається курсивом.

Рис. 1


Відносини (relationship) між класами в UML зводяться до чотирьох базових типів:



Розглянемо зараз тільки два з них – асоціацію та узагальнення.


Асоціація вказує на наявність певної зв’язку між класами, наприклад, «відділ-співробітники”. Вона відображається суцільною лінією (рис. 2). Лінія асоціації може з’єднувати два (бінарна асоціація) або більше (N-асоціація) класів. В останньому випадку місце з’єднання декількох асоціацій позначається ромбом (на рис. 2 представлена ​​бінарна асоціація). Асоціація може мати ім’я, в цьому випадку воно розташовується над лінією асоціації (на рис. 2 ім’я відсутнє). Кінців лінії асоціації – ролям – даються назви. В даному випадку асоціація має ролями «Включає» і «Працює в». Крім того, кінці лінії асоціації мають позначення розмірності, які вказують на кратність відносини. Так, з рис. 2 можна зробити наступні висновки щодо описуваної моделі (тобто відновити закладені в неї бізнес-правила):

Рис. 2



Легко помітити уявну аналогію між асоціацією в UML і реляційними відносинами типу «один до багатьох» і «багато до багатьох» в СУБД. Однак далеко цю аналогію провести не вдасться. По-перше, в реляційної БД зв’язок «багато до багатьох» не може поєднувати дві таблиці – для цього обов’язково потрібна ще одна проміжна таблиця. В UML же це цілком допустимо. По-друге, кратність в UML в принципі може бути будь-який, в тому числі і нульовий. Так, якби ми на кінці асоціації, що вказує на співробітника, написали «0 .. n», то це означало б, що можуть існувати відділи, які не мають жодного співробітника. А якщо б ми поставили кратність «15 .. 50», то це говорило б про те, що чисельність співробітників у відділі не може бути менше 15 і більше 50.


Не можна не згадати і ще про один важливий варіанті використання асоціації. Розглянемо UML-модель, зображену на рис. 3. У ній обидва кінці асоціації підключені до одного і того ж класу та визначають наступні бізнес-правила:

Рис. 3



Використання асоціацій в такому варіанті нерідко зустрічається при створенні моделей додатків.


Другим типом розглянутих відносин є узагальнення, або генералізація. Даний тип ставлення вказує, що між класами існує зв’язок типу «предок-нащадок», аналогічна відношенню спадкування в ООП. Такий зв’язок відображається лінією зі стрілкою у формі порожнього трикутника, причому трикутник-стрілка вказує на «предка», тобто на батьківський клас. Так, на рис. 4 показано ставлення узагальнення між батьківським класом «Людина» і дочірнім класом «Громадянин». При цьому необхідно враховувати, що всі атрибути класу-батька автоматично належать і класу-нащадка, хоча в ньому не відображаються. Тому клас «Громадянин», окрім представлених в ньому атрибутів «Громадянство» і «Номер посвідчення особи», включатиме й атрибути «Ім’я», «Вага» і «Рост». Відносини узагальнення досить часто використовуються при побудові моделей, при цьому як класу-батька нерідко виступає небудь абстрактний клас.

Рис. 4


Отже, ми ознайомилися з базовими поняттями, використовуваними при побудові діаграм класів. Надалі ми поговоримо і про деякі інші можливості і властивості UML.


Тег-параметри (tagged values)


Для функціонування Bold крім UML-моделі використовується набір спеціальних змінних-параметрів (tagged values), або тег-параметрів. Вони необхідні для взаємодії з середовищем розробки і СУБД, а також для додаткових налаштувань моделі.


Поява тег-параметрів не випадково. Якщо UML-модель можна розглядати як переносних незалежну PIM-модель, то сукупність тег-параметрів можна вважати елементом платформенно-залежної PSM-моделі. Будучи з цієї причини пов’язаними з PIM, тег-параметри класифікуються за належністю до елементів ієрархічної структури моделі. Таким чином, існують окремі набори тег-параметрів для наступних елементів ієрархії моделі:



Тег-параметри можна також класифікувати і за функціональною приналежності:



Розробник також може створювати власні тег-параметри і використовувати їх для своїх цілей. Значення тег-параметрів доступні як на етапі розробки програми, так і під час його виконання.


Bold включає кілька десятків тег-параметрів. Ми розглянемо їх, коли мова піде про технології розробки моделей додатків для Bold в UML-редакторах. Цій темі буде присвячена наступна частина даної публікації.

Частина 4

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


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

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

Ваш отзыв

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

*

*