Тенденції у розвитку мови UML і розробки ПЗ

Уніфікована мова моделювання (UML) завоював широке визнання в якості стандартного галузевого мови для визначення, візуалізації, створення та документування артефактів програмних систем. Він спрощує складний процес проектування ПЗ шляхом створення "креслення" для побудови системи. Створенням мови UML керували провідні фахівці з методології компанії Rational Software – Грейді Буч (Grady Booch), Івар Якобсон (Ivar Jacobson) і Джим Рамбо (Jim Rumbaugh). У цій статті Джим Рамбо ділиться своєю думкою про нову епоху розробки ПЗ, про її вплив на нові вимоги, що висуваються до мови UML, і про оптимальні методи їх виконання.


Нова епоха розробки ПЗ


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


Електронний світ тепер розподілений, паралельний і взаємопов'язаний. Розподілений – оскільки інформація розміщена в багатьох різних місцях по всьому світу. Часи єдиних центральних комп'ютерів давно пройшли. Паралельний – оскільки діяльність відбувається децентралізовано і одночасно. Одного потоку керування тепер недостатньо ні для ухвалення ділового рішення, ані для виконання програм. Взаємопов'яза – оскільки будь-яку дію в одному місці може значно вплинути на навколишній світ. Філіппінська творець вірусу може відключити половину серверів планети. Прості комп'ютерні системи, мови і моделі минулого не можуть відповідати сучасним вимогам.


У цьому новому світі існує безліч рушійних факторів. Десять років тому більшість людей в комп'ютерній галузі вважали Інтернет дослідної забавою – зараз у кожної піцерії (принаймні в Каліфорнії) є своя web-сторінка. Зростає число компаній, що довіряють критично значимі операції системам розподілених об'єктів підприємства. Ці об'єктно-орієнтовані системи містять розподілені сервери і бази даних, об'єднані для підтримки високопараллельних бізнес-операцій. Все більше число галузей для здійснення своєї діяльності змушене взаємодіяти в режимі реального часу. Банки, авіалінії і телефонні компанії не можуть працювати без інтенсивного обміну інформацією між усіма дійовими особами. Нарешті, пристрої реального часу зустрічаються тепер всюди – в машинах, приладах, побутовій електроніці, будівлях. Проблеми їх роботи перестали бути вузькою спеціалізованої областю і стосуються тепер кожного з нас.


Новий електронний світ несе з собою великі можливості, але вони даються ціною високих витрат на розробку. У надзвичайно складних взаємодіях паралельних розподілених систем дуже важко розібратися, не кажучи вже про пророкування. Основною проблемою є нечіткі визначення. Раніше визначення монолітної системи впливали лише на неї саму, і якщо вона працювала не в точній відповідності з визначеннями, ніхто особливо не переймався. Але сучасній бізнес-системі може знадобитися взаємодія з системою на іншому кінці земної кулі, причому обидві могли бути створені людьми, ніколи не чули один про одного. Помилка в проходженні визначень може викликати помилки, що поширюються по всьому світу. З розподіленої системи не можна зняти резервну копію і її не можна перезапустити, якщо в будь-якій частині виявиться збій. Система в цілому повинна працювати, незважаючи на збої, помилки або псування даних у деяких її частинах. Більшість сучасних систем є системами реального часу. Велике значення для клієнтів і партнерів має узгодженість за часом. І на завершення, продуктивність складних систем часто буває нелінійної і не може бути передбачена шляхом простої екстраполяції.


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


Мова UML в електронному світі


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


Розробка мови UML розпочалася в компанії Rational в 1995 році з об'єднання методів Буча та OMT. Процес розробки було вирішено зробити загальнодоступним. У 1997 році створена спільними зусиллями багатьох компаній специфікація мови була прийнята групою OMG (робочою групою з розвитку стандартів об'єктного програмування). Це була мова UML версії 1.1. Компанія Rational потім передала права на UML групі OMG cцелью зробити цю мову загальнодоступним стандартом. З тих пір комісія OMG, куди входять представники різних компаній, працювала над роз'ясненням і виправленням помилок вихідної специфікації, випустивши її оновлення в 1998 р. (версія 1.3). Випуск другого поновлення очікується в кінці 2000 р. (версія 1.4). Активну участь у роботі комісії взяли експерти компанії Rational. У процесі оновлення було усунуто багато внутрішні проблеми в метамоделі мови UML, пояснені невизначеності вихідного документа, покращено однаковість позначень і виправлений ряд засобів, що використовуються в спеціалізованих областях. Але в Загалом і в цілому, більшість звичайних користувачів не помітить багатьох відзнак. Мабуть, найбільш істотною зміною у версії UML 1.3 став перегляд формулювань відносин між прецедентами, але навіть це не представляє собою дуже велику модифікацію. Найбільш значним доповненням версії UML 1.4 стануть керівництва щодо створення профілів – адаптацій мови UML для конкретних прикладних областей. Звичайно, специфічні деталі мови зазнали багато змін, але загалом мова UML поки залишається тією ж мовою з тими ж можливостями, що і початкова версія.


Зусилля компанії Rational з розширення мови UML


Паралельно з роботою по очищенню документації з UML було зроблено декілька ініціатив щодо розширення мови UML для нових прикладних областей, включаючи системи і бази даних Web. Деякі з цих ініціатив були зроблені групою OMG, інші – окремими компаніями, такими як Rational.


Щоб не відстати від швидко мінливого світу електронного бізнесу, майже всім компаніям необхідна розробка своїх web-систем. Джим Коннален (Jim Conallen) разом з іншими фахівцями Rational розробив спосіб моделювання web-систем за допомогою мови UML і додатки Rational Rose. Ця можливість пропонується у вигляді профілю UML, що дозволяє розробникам моделей представляти різні види елементів web-додатки – клієнтські та серверні сторінки, форми, кадри і т.д. Профіль містить набір стереотипів для різноманітних елементів і їхніх стосунків. Цей підхід описаний в книзі Коналлена Building Web Applications with UML (Addison Wesley Longman, 2000). Даний профіль входить до складу останніх версій Rational Rose.


Майже всі програми електронного бізнесу використовують бази даних. Однією з найбільш складних проблем розробки систем довго було координування мов програмування і баз даних, оскільки їх різні способи оголошення структури даних призводять до невловимим суперечностей і труднощів при перенесенні інформації між програмами та базами даних. Використання єдиної моделі UML, що лежить в основі як програмного коду, так і схем баз даних, дозволяє уникнути багатьох з цих проблем. Компанія Rational розробила для UML профіль моделювання баз даних, який підтримується у різних версіях програми Rational Rose. Цей профіль дозволяє розробнику сконструювати логічну модель інформації і модель таблиць фізичної бази даних, отриману на основі цієї інформації. Наявність двох моделей дозволяє розробнику налаштувати і оптимізувати структуру бази даних, що має важливе значення при розробці баз даних. Оскільки обидві моделі пов'язані між собою, зміни в одній з них відбиваються на інший, що дозволяє уникнути протиріч.


Ініціативи групи OMG


Ініціативи групи OMG реалізуються через процес створення RFP (запитів на пропозиції). Робоча група OMG визначає існуючу потребу і випускає RFP з формулюванням вимог та рекомендацією компаніям-учасникам пропонувати свої рішення. Звичайно кілька компаній об'єднуються разом для подачі спільної пропозиції. Група OMG пропонує подавачам окремих пропозицій не втягуватися в суперечки, а спільно виробити об'єднані пропозиції. Це змушує йти на компроміс, який, незважаючи на часте роздування змісту пропозиції, також сприяє його загальному прийняття – бажаної мети будь-якого стандарту. З цих причин мова UML більш заплутаний, чим він міг би бути, будучи жорстко узгодженим з поглядами однієї компанії, але зате більш всеосяжний і загальноприйнятий.


Нижче наведено кілька основних ініціатив OMG.


Моделювання систем реального часу – Найважливіша ініціатива, що додала у мову UML можливість моделювання систем реального часу і розроблена під керівництвом Брена силіка (Bran Selic) з компанії Rational. З-за свого великого обсягу ця робота була розбита на кілька менших RFP. Перший запит стосується моделювання аспектів часу, планування та продуктивності. Початкове пропозиція була нещодавно представлено консорціумом, включає всіх лідерів у галузі моделювання систем реального часу (тому цю пропозицію, ймовірно, буде прийнято). Кожне вихідне пропозиція повинна спочатку отримати відгуки від членів OMG, а потім пройти повторно, тому ця робота буде завершена в наступному році. Після цього, ініціатори пропозиції про моделювання систем реального часу піднімуть наступну частину проблеми: моделювання надійності та відмовостійкості. Найімовірніше, друге речення буде подано тими ж розробниками.


Важливим аспектом систем реального часу є їхня архітектурна структура. У 1999 році ми з разом з Брена силікою розробили профіль UML під назвою UML-RT, який дозволяє ієрархічно будувати системи з інкапсульованих модулів (капсул) з чітко визначеними інтерфейсами (портами) і явними каналами зв'язку (з'єднувачами). З тих пір ми виявили, що ці архітектурні концепції корисні для більшості систем. У той же час, підготовка до наступного значного оновлення мови UML (версії 2.0) показала, що деякі інші експерти і мови моделювання використовують дуже схожі концепції. Подібними концепціями володіє, наприклад, мова SDL, використовуваний в телекомунікації, а також деякі мови опису апаратного забезпечення. Таким чином, впровадження в мову UML конструкцій архітектурного моделювання є частиною загальної роботи щодо його розширення і не буде обмежена тільки групою з моделювання систем реального часу.


Певна модель виконання – Відсутність цієї моделі є, можливо, найбільш великим недоліком вихідної специфікації мови UML. Статична структура моделей UML отримала чітке визначення, але послідовності виконання цих моделей були лише розпливчасто словесно описані. Пропуск точної специфікації поведінки моделей при виконанні був спочатку вірним рішенням, оскільки нашою метою було визначення та опублікування конструкцій UML. Проте, один з перших запитів на пропозицію по розширень UML полягав у визначенні дій, підтримуваних UML, і семантики їх виконання. З боку Rational ця робота проводилася Брен силікою і мною в співпраці з фахівцями інших компаній, що займаються моделюванням систем реального часу, мовами опису дій і телекомунікаціями. Всі учасники об'єдналися в єдину команду. Перша версія цієї пропозиції нещодавно була подана на розгляд. У ньому міститься модель виконання, підтримуюча високопараллельние дії без зайвих визначень управління, необхідних в основних мовах програмування. Ця пропозиція націлене не на винахід ще однієї мови програмування, а на створення семантичної бази, на основі якої в UML можна точно визначити вплив мов програмування.


Обробка даних підприємства – В цій області було висунуто кілька ініціатив. Попереду розгляд пропозицій по розподіленої об'єктної обробки даних підприємства (EDOC, Enterprise Distributed Object Computing) та інтеграції додатків підприємства (EAI, Enterprise Application Integration). Ці пропозиції істотно збігаються між собою (побічний ефект демократичних методів групи OMG), але вони подані практично одними і тими ж розробниками, уживають заходів з координації обох пропозицій. Ці ініціативи будуть визначати профілі, описують способи створення великих, розподілених, паралельних систем підприємства, керованих подіями. У компанії Rational цей напрямок очолює Войтек Козачинський (Wojtek Kozaczynski).


Процес розробки – Інша ініціатива стосується структури визначення процесів розробки програмного забезпечення. Її створення могло б забезпечити стандартний спосіб визначення таких процесів, як RUP (Rational Unified Process). Рекомендувача заявляють, що це дозволить організаціям використовувати кілька процесів і легко порівнювати їх між собою. Я скептично ставлюся до цього твердження – на мою думку, організація повинна вибрати один процес і дотримуватися його, – але в будь-якому випадку, можливість висловити процес RUP в такій структурі досить важлива, тому компанія Rational бере участь у цій ініціативі. З боку Rational цю роботу веде Філіп Крюхтен (Philippe Kruchten).


Інші ініціативи – Існує також ще кілька пов'язаних ініціатив, таких як стандарт зберігання даних, зіставлення CORBA і UML, а також формат XMI для обміну моделями UML в текстовому форматі. Існують групи, що створюють профілі на основі UML для різних прикладних областей, але я не буду їх обговорювати, оскільки вони представляють швидше способи використання мови UML, ніж його зміна.


Робота над створенням UML 2.0

Як стандарт UML у багатьох відношеннях подібний мови програмування. Використовуючи мову, люди відкривають потреби внесення до нього нових можливостей. Проте, дуже часта зміна мови небажано – Користувачам потрібен час, щоб зрозуміти нову версію і накопичити досвід її використання. Розробка інструментів (таких як Rational Rose) підтримки мови також вимагає часу і занадто швидке його зміна призводить до ризику втрати цієї інструментальної підтримки. Тим не менш, для підтримки виникаючих нових потреб мовам необхідно розвиток. На мою думку, докорінне оновлення мов, включаючи UML, повинно проводитися приблизно через кожні п'ять років. Деякі розробники UML наводять аргументи на користь більш швидких змін, але я думаю, що це думка неадекватно завищує переваги нових можливостей в порівнянні з вартістю нестабільності. У будь-якому випадку, такий політичний, заснований на роботі комісії процес, як робота групи OMG (або будь-якої організації, що займається стандартами), досить інерційний, тому еволюція мови UML вимагає часу незалежно від бажання людей.


Планування нової версії UML вже почалося. Група OMG розіслала запит на пропоновані зміни, на який було отримано майже 30 відповідей. Деякі відповіді стосувалися лише конкретних областей, інші містили довгі списки пропонованих нових можливостей. Для отримання більш короткого списку змін, які можуть бути реалізовані в розумні терміни, відповіді були стиснуті і розбиті за пріоритетами. Результатом з'явився набір RFP, випущений групою OMG в вересні 2000 року.



Після розробки змін для UML 2.0 на них буде накладено вимога підтримки максимально можливої сумісності з існуючими моделями UML. Розробники та їх компанії вклали великі інвестиції в свої моделі і необхідність зміни цих моделей украй небажана. Крім того, в тих питаннях, в яких для задоволення нових потреб можуть бути розширені існуючі концепції, поширення нових концепцій має бути обмежена. У той же час буде зроблена спроба позбутися від зайвих концепцій, особливо від стереотипів, що мають лише імена без семантичного опису. (Підказка: якщо визначення складається з одного або двох пропозицій без структури або семантики – це ймовірний кандидат на видалення.)


Робота буде проводитися у дві стадії з отриманням проміжних відгуків. Планована дата її завершення – січень 2002 року. Я очікую, що створення UML 2.0 затягнеться до кінця року. (Я не боюся давати прогнози у пресі. Перевіримо їх правоту через два роки.) Я очікую, що над різними областями цього завдання будуть працювати консорціуми з кількох компаній. За деякими запитам можуть бути кілька пропозицій, але я розраховую на співпрацю розробників в об'єднанні своїх пропозицій на другій стадії проекту. Найбільшою проблемою буде обмеження розмноження засобів мови, що завжди важко здійснити в політичному процесі.


Перспективи

Сьогодні UML є цілком придатним і зручним мовою, тому не слід відкладати його вивчення тільки тому, що він буде розширений через два роки. Велика частина UML залишиться незмінною, а більшість його розширень швидше вплинуть на межі його застосування, ніж змінять існуючу семантику. Подібно будь-якій мові, включаючи той, на якому написана ця стаття, UML є живою мовою, що розвиваються відповідно до мінливими потребами. Його широке визнання разом з можливістю розширення повинні переконати будь-якого потенційного користувача UML у необхідності докладання зусиль для вивчення цього мови.


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


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

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

Ваш отзыв

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

*

*