У результаті в 1990-е рр. підхід CASE робив порівняно невеликий вплив на розробку комерційного програмного забезпечення, фокусуючись на декількох прикладних областях, наприклад, на обробці викликів у телекомунікаційних системах, де добре підходили подання у вигляді кінцевих автоматів. Навіть там, де CASE-Засоби застосовувалися на практиці, звичайно використовувалася тільки їхня частина, що дозволяє розроблювачам малювати діаграми програмних архитектур і документувати свої рішення, на основі чого програмісти потім вручну робили й розвивали реалізації. Однак, оскільки був відсутній прямий зв'язок між діаграмами й реалізаціями, розроблювачі не прагнули до великої точності діаграм, оскільки вони рідко синхронізувалися із кодом на подальших стадіях проектів.
В останні двадцять років досягнення в області мов програмування й платформ привели до підвищення рівня абстракцій, доступних для розроблювачів, зм'якшивши один з недоліків підходу CASE. Наприклад, сьогодні розроблювачі звичайно використовують більше виразні об’єктно-орієнтовані мови (зокрема, C++, Java і C#), а не Fortran або C. Повторно використовувані бібліотеки класів і платформи підтримки додатків мінімізують потребу у винаході загальних і прикладних сервісів - транзакцій, відмовостійкості, оповіщення про події, безпеку, розподіленого керування ресурсами й т.д. Все це дозволяє розроблювачам краще захиститися від складності, пов'язаної зі створенням додатків на основі традиційних технологій.[14]
Незважаючи на ці досягнення, залишається кілька неприємних проблем. У центрі цих проблем лежить складність платформ, що росте швидше здатності мов загального призначення маскувати її. Наприклад, популярні платформи проміжного програмного забезпечення J2EE, .NET і CORBA містять тисячі класів і методів з багатьма складними залежностями й тонкими побічними ефектами, що вимагає значних зусиль при програмуванні й ретельному настроюванні.
Родинна проблема полягає в тому, що код більшості додатків і платформ як і раніше пишеться на мовах третього покоління, для чого потрібно багато часу й зусиль, особливо для виконання інтеграційних дій - розгортання, конфігурування й підтримка якості системи. Наприклад, на Java або C# важко написати код, коректно й оптимально розгортає великомасштабної розподіленої системи із сотнями тисяч взаємозалежних компонентів.
Ситуацію не рятує навіть використання описів розгортання мовою XML, використовуваних у компонентних і сервіс-орієнтованих платформах проміжного програмного забезпечення, оскільки в цьому випадку є семантичний розрив між метою розробки й вираженням цієї мети в тисячах рядків вручну зробленого XML, синтаксис якого не має відносини ні до семантики прикладної області, ні до мети розробки. Через наявність цих проблем індустрія програмного забезпечення наближається до гранично припустимої складності.
У той же час платформні технології нового покоління, наприклад, Web-Сервіси й архітектури продуктових ліній (product-line architecture) стають настільки складними, що роками опановують платформними API і паттернами використання й при цьому часто виявляються знайомими тільки із частиною можливостей регулярно використовуваної ними платформи. Більше того, при використанні мов третього покоління розроблювачі змушені приділяти настільки велику увагу тактичним деталям імперативного програмування, що вони часто не можуть концентруватися на стратегічних архітектурних проблемах, таких як коректність системи в цілому і її продуктивність. Такі фрагментовані представлення проекту в цілому затрудняють розроблювачам розуміння того, які частини їхніх додатків є чутливими до побічних ефектів, що виникають при зміні вимог замовників і/або середовища розробки. Часто це змушує розроблювачів робити неоптимальні рішення, у яких дублюються частини коду, порушуються ключові архітектурні принципи, ускладнюється розвиток системи й забезпечення необхідної якості.
Багатообіцяючим підходом, спрямованим на рішення цих проблем, є розробка технологій інженерії, керованої моделями, (Model-Driven Engineering, MDE). При використанні MDE розробка ведеться на предметно-предметно-орієнтованих мовах моделювання (Domain-Specific Modeling Language, DSML), у системах типів яких формалізується структура, поводження й вимоги додатка усередині відповідної предметної області. DSML описуються з використанням метамоделей, у яких визначаються зв'язки між поняттями предметної області й точно специфується основна семантика й обмеження, асоційовані із цими поняттями. [10.1]
5. Огляд англомовної літератури UML
Для того щоб добре орієнтуватися в UML, тобто успішно використовувати його на практиці, треба мати досить глибокі представлення про методи об’єктно-орієнтованого аналізу, проектування й програмування. Приведу список англомовної літератури по UML з коротким описом змісту кожної роботи. Цей список не претендує на повноту, але, по -моєму, дає деяке подання про літературу, що описує UML.
Перша група робіт - [4], [5], [6]
[4], Booch G. Object-oriented analysis and design with applications. Second edition. The Benjamin/Cummings Publishing Company, Inc. 1994. 589 p.//
[5] Rumbaugh J., Blacha M. Premerlani W., Eddy F. Lorensen W. Object-Oriented Modeling and Design. Prentice-Hall, Inc., 1991
[6] Jacobson I. Object-Oriented Software Engineering. A Use Case Driven Approach. Addison-Wesley Publishing Company, 1993.
містить опис об’єктно-орієнтованих методологій, які були покладені в основу UML.
[5] є описом методології OMT. Вона вийшла в 1991 році й на справжній момент існує багато CASE-Засобів, у тім або іншому ступені підтримуючих її. До UML ця методологія була однієї з найпоширеніших.
[4] є, очевидно, кращою книгою в цій області. Вийшло два її видання - перше в 1991 році, друге - в 1994. Обоє видання перекладені на російську мову.
[6] містить опис OOSE - об’єктно-орієнтованого підходу до створення програмних систем, заснованого на моделі випадків використання (use case driven approach) і є систематизацією більш ніж 20-літнього досвіду її автора, Айвара Джекобсона, в області створення більших систем. Ця книга вийшла у світло в 1992 році. Модель випадків використання й багато чого, з нею зв'язане, увійшли в UML.
Друга група літератури є канонічним описом стандарту UML
[2] Booch G.,Rumbaugh J. UML 1.1. Semantics. 1997.
і [7] Booch G., Rumbaugh J. UML 2.0. Notation Guide є основними документами по UML. Там описується метамодель UML і дуже мало уваги приділяється семантиці конструкцій. В [8] (A Rational Approach to Software Development Using Rational Rose 4.0 )описується приклад розробки програмної системи (реєстрація студентів на відвідування навчальних курсів) з використанням CASE-Засобу Rational Rose, що реалізує підмножину UML (аналіз і проектування). Всі ці документи вільно доступні і їх можна взяти на web-вузлі OMG.
Оскільки офіційна документація по UML скрутна для розуміння, виходить багато книг, що описують його з різними акцентами. Я відзначу книги, написані головними авторами UML - Г. Бучем, И Джекобсоном, Д. Рэмбо - [1], [11], [12]:
· [1] - G. Booch, Jim Rumbaugh, Ivar Jacobson The Unified Modeling Language User Guide: детальна інформація про використання UML. Покриває близько 80% мови. Застосування UML описується на великій кількості прикладів;
· [11] Ivar Jacobson, G. Booch, Jim Rumbaugh The Unified Software Development Process - опис процесу об’єктно-орієнтованої розробки ПО;
· [12] - J.Rumbaugh, I.Jacobson, G. Booch Unified Modeling Language Reference Manual: - довідник по UML, що охоплює вся мову.
Крім того, відзначу ще книгу [13] (B.P. Douglass Real-Time UML. Developing Efficient Objects for Embedded Systems), написану співробітником фірми i-Logix Брюсом Дугласом, у якій утримується гарний опис UML у контексті розробки систем реального часу.
Ще одним джерелом інформації з UML є матеріали, що випускаються компанією Rational Software Corp. Це насамперед величезна база даних RUP, що містить більше 1000 статей навколо UML. Крім того, із грудня 1998 року виходить у світло журнал "Rose Architect", що містить багато цікавих статей фахівців фірми Rational Software Corp. про UML, RUP, Rational Rose, про застосування Rational Rose у різних областях розробки ПО.
Нагадаю, початковою метою розвитку UML було забезпечення більш точного опису мови моделювання - підтримка формальної основи для розуміння мови моделювання. Однак дотепер формальна семантика не є частиною стандарту. Огляд декількох підходів, що стосується визначення такої семантики, наведений в [26] (Husman H. Loose Semantics for UML), де розглянуті теоретико-множинний, трансляційний, метамодельний підходи й запропонований так звана “вільна семантика”.
Слід зазначити, що в самій специфікації UML існує багато огріхів і протиріч: так, у роботі [27] (Genova G., Llorens J., Quintana V. Digging into Use Case) розглядаються відносини включення й розширення для варіантів використання, в [29] (Gogolla M., Henderson-Sellera B. Analysis of UML Stereotypes within the UML Metamodel) аналізуються стандартні стереотипи метамоделі UML. У роботі [30] (Naumenko A., Wegmann A. A Metamodel for the Unified Modeling) пропонується використовувати RMODP ((Reference Model Open Distributed Processing) [31] (RM-ODP Open Distributed Processing - Reference) для рішення проблем мови. Відзначу, що відповідно до специфікації UML модель RM-ODP виступає структурою, що безпосередньо впливає на архітектуру метамодели мови (розділ “Preface: Relationships to Other Models”). Крім того RM-ODP використовується в MOF (Meta-Object Facility) для керування типами. В [30] (Naumenko A., Wegmann A. A Metamodel for the Unified Modeling) ідентифікуються три проблеми метамоделі UML і пропонується їхнє рішення на базі RM-ODP:
- структурний хаос семантики мови - “висока техніка, лаконічність і складність для розуміння новачками”; рішення: використання структури RM-ODP і теорії типів Б. Расела;
- відсутність декларативної семантики, суперечливість семантики мови при описі відносин між моделями, побудованими з використанням мови, і безпосередньо суб'єктів моделювання; рішення: реалізація базової концепції моделювання (Basic Modeling Concept);
- недостатнє теоретичне обґрунтування використовуваної метамоделі мови UML; рішення: пропонована в статті концепція моделювання на основі RM-ODP, теорії типів Б. Расела до інтерпретації формальних вирахувань уважається повністю обґрунтованою.
У багатьох роботах, присвячених формалізації моделі й метамодели мови UML, розглядається не сама мова, а деяка його підмова, формальна й строго структурований. Так, в [32] / (Paige R., Ostroff J. Metamodelling and Conformance Checking with PVS) розглядаються BON (Business Object Notation, об’єктно-орієнтована мова моделювання, по суті співпадаюча з підмовою діаграм класів UML [33] (Walden K., Nerson J.-M. Seamless Object-Oriented Software Development) і PVS (Prototype Verification System, мова специфікацій, розроблена для автоматичного аналізу метамоделей мов моделювання [34]( Owre S., Shankar N., Rushby J., Stringer-Calvert D. The PVS Language Reverence Version 2).