49299 (666218), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

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

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

OMG (Object Management Group) відповідає на цю вимогу підготовкою версії 2.01 мови UML і ініціативою MDA (Model Driven Architecture). Проблеми, на рішення яких на початку були націлені розроблювачі UML 2.0, включали очевидне розпухання ранніх версій UML і відсутність правильно певної семантики.

У ході розробки стандарту в число вимог була додана підтримка модельно-модельно-керованої розробки (MDD), а точніше, підходу MDA до MDD. Широка поінформованість про проблеми ранніх версій UML разом зі зростаючим інтересом до MDD породили надії на те, що розроблювачам UML 2.0 удасться зробити версію мови з істотно скороченим набором модельних понять для точного й зручного описів найрізноманітніших додатків.

Очікувалося також, що в цій версії буде бути точна семантика, що могла б полегшити автоматизацію, необхідну для просування MDD за межі традиційних можливостей існуючих CASE-Засобів. Деякі люди очікували, що розроблювачам UML 2.0 удасться зробити срібну кулю мов моделювання або, принаймні, тісно наблизитися до цього.

Ті, хто не знаком із внутрішніми роботами в області, проведеній співтовариством стандартизації мов, знаходять разючими розмір і складність стандарту UML 2.0. Дійсно, кінцеві результати здаються далекими від посилок, які мотивували початок цієї роботи з великого перегляду мови. З погляду очорнителя, численні модельні поняття, погано певна семантика й легковагі механізми розширень затрудняють вивчення мови і його застосування в середовищі MDD. Ці реальні проблеми вимагають рішення, але нам не слід дивуватися тому, що ця мова моделювання першого покоління далека від досконалості.

Як відзначають деякі розроблювачі UML, розробка мов моделювання усе ще переживає період становлення. Для прискорення процесу виявлення знань, пов'язаних з MDD, нам потрібна конструктивна критика UML. У цьому змісті UML 2.0 може зіграти важливу роль як явна форма експерименту з мовою моделювання, що може вивчатися, аналізуватися й критикуватися зацікавленими сторонами.

Захисники UML 2.0 відзначають, що в цьому стандарті відбитий кращий виробничий досвід застосування моделювання. Вони говорять про наступні основні вдосконалення:

• Поліпшено підтримку UML як сімейства мов за рахунок використання профілів і крапок семантичних варіацій (semantic variation point), які позначають частини UML, які навмисне залишені без семантики, щоб можна було навантажити їхньою семантикою, обумовленої користувачами.

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

• Зроблено інтеграцію семантики дій (Action Semantics), що може використовуватися розроблювачами для визначення семантики моделей під час виконання й забезпечує семантичну точність, необхідну для аналізу моделей і їхньої трансляції в реалізації.

На думку авторів, що занадто висока оцінка UML і відповідних технологій MDD може бути настільки ж пагубної, як і несправедлива критика. Це може привести до росту очікувань користувачів до недосяжного в цей час рівня. У своїй статті автори намагаються розвіяти хмари реклами, що оточують UML 2.0, і представити обґрунтовану оцінку забезпечуваної цієї версії мови підтримку MDD [10.4].

6. Критика й переваги UML

Незважаючи на те, що UML досить широко розповсюджений і використовуваний стандарт, його часто критикують через наступні недоліки [40, 41]:

• Надмірність мови. UML часто критикується, як невиправдано велика і складна. Вона включає багато надлишкових або практично невикористовуваних діаграм і конструкцій. Частіше це можна почути у відношенні UML 2.0, чим UML 1.0, тому що більше нові ревізії включають більше « розроблених-комітетом» компромісів.

• Неточна семантика. Тому що UML визначена комбінацією себе (абстрактний синтаксис), OCL (мовою опису обмежень — формальної перевірки правильності) і Англійської (докладна семантика), то вона позбавлена скутості властивим мовам, точно певним техніками формального опису. У деяких випадках абстрактний синтаксис UML, OCL і Англійської суперечать один одному, в інших випадках вони неповні. Неточність опису самої UML однаково відбивається на користувачах і постачальниках інструментів, приводячи до несумісності інструментів через унікальне трактування специфікацій.

• Проблеми при вивченні й впровадженні. Вищеописані проблеми роблять проблематичним вивчення й впровадження UML, особливо коли керівництво насильно змушує використовувати UML інженерів при відсутності в них попередніх навичок (стаття ACM "Death by UML Fever" на англ. містить цікаве оповідання про кількість таких випадків.) [41]

• Тільки код відображає код. Ще одна думка — що важливо робочі системи, а не гарні моделі. Як лаконічно виразився Джек Ривс, «The code is the design» (англ. «Код і є проект»). Відповідно до цієї думки, існує потреба в кращому способі написання ПЗ; UML цінується при підходах, які компілюють моделі для генерування вихідного або здійсненного коду. Однак цього все-таки може бути недостатньо, тому що UML не має властивостей повноти по Тьюрінгу і будь-який згенерований код буде обмежений тим, що може розглянути або припустити інтерпретуючий UML інструмент.

• Кумулятивне навантаження/Неузгодженість навантаження (Cumulative Impedance/Impedance mismatch). Неузгодженість навантаження — термін з теорії системного аналізу для позначення нездатності входу системи сприйняти вихід іншої. Як у будь-якій системі позначень UML може представити одні системи більш коротко й ефективно, чим інші. Таким чином, розроблювач відмінюється до рішень, які більш комфортно підходять до переплетенню сильних сторін UML і мов програмування. Проблема стає більш очевидної, якщо мова розробки не дотримується принципів ортодоксальної об’єктно-орієнтованої доктрини (не намагається відповідати традиційним принципам ВОП).

• Намагається бути всім для всіх. UML — це мова моделювання загального призначення, що намагається досягти сумісності з усіма можливими мовами розробки. У контексті конкретного проекту, для досягнення командою проектувальників певної мети, повинні бути обрані застосовні можливості UML. Крім того, шляхи обмеження області застосування UML у конкретній області проходять через формалізм, що не повністю сформульований, і який сам є об'єктом критики. [40]

Переваги UML

Підсумую:

• UML об’єктно-орієнтована, у результаті чого методи опису результатів аналізу й проектування семантично близькі до методів програмування на сучасних ВО-Мовах;

• UML дозволяє описати систему практично із всіх можливих точок зору й різні аспекти поведінки системи;

• Діаграми UML порівняно прості для читання після досить швидкого ознайомлення з його синтаксисом;

• UML розширює й дозволяє вводити власні текстові й графічні стереотипи, що сприяє його застосуванню не тільки в сфері програмної інженерії;

• UML одержала широке поширення й динамічно розвивається.

7. Висновок

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

Перелік літератури

[1] G. Booch, Jim Rumbaugh, Ivar Jacobson The Unified Modeling Language User Guide: Addison-Wesley Publishing Co., 1999, 512 p.

[2] Booch G., Rumbaugh J. UML 1.1 Semantics. (http://www.rational.com/uml/)1997.

[3]RogerR.Flynn,EditorinChief,Computersciences.Volume2.SoftwareandHardware.MacmillianreferenceUSA.ThomsonGaleCompany,Inc.2002572p.

[4]BoochG.Object-orientedanalysisanddesignwithapplications. Secondedition.TheBenjamin/CummingsPublishingCompany,Inc.1994.589p.//

[5]RumbaughJ.,BlachaM.PremerlaniW.,EddyF.LorensenW.Object-OrientedModelingandDesign.Prentice-Hall,Inc.,1991

[6]JacobsonI.Object-OrientedSoftwareEngineering. AUseCaseDrivenApproach.Addison-WesleyPublishingCompany,1993.

[7]BoochG.,RumbaughJ.UMLNotationGuide(www.rational.com/uml/)1997.

[8]ARationalApproach toSoftwareDevelopment Using Rational Rose4.0http://www.rational.com/support/techpapers/roseapproach/. 1997

[9] OMG Unified Modeling Language Specification (draft). Version 1.3R9. (http://www.rational.com/uml/)1999.

[10]Computer(IEEEComputerSociety,V.38,No2,February2005)"Model-DrivenSoftwareDevelopment"

[10.1]Model-DrivenEngineering("Керована моделями інженерія"), Douglas C. Schmidt

[10.2] Developing Applications Using Model-Driven Design Environments. (Розробка додатків з використанням керованих моделями середовищ розробки"). K.Balasubramanian, A.Gokhale, G.Karsai, J.Sztipanovits, S. Neema.

[10.3] CALM and Cadena: Metamodeling for Component-Based Product-Line Development. ("CALM і Cadena: метамоделювання для заснованої на компонентах розробки продуктового ряду")A.Childs, J.Greenwald, G.Jung, M.Hoosier, J.Hatcliff

[10.4]Automating Change Evolution in Model-Driven Engineering ("Автоматизація еволюції змін у модельно-модельно-керованій інженерії"") Джеф Греq, Джейн Лін і Джинг Жанг.

[10.5] Model-Driven Development Using UML 2.0: Promises and Pitfalls. S.Ghosh, Trung Dinh-Trong, A. Solberg. ("Модельно-модельно-орієнтована розробка з використанням UML 2.0: обіцянки й прорахунки"

[11] Ivar Jacobson, G. Booch, Jim Rumbaugh The Unified Software Development Process: Addison-Wesley Publishing Co., 1999, 512 p.

[12] Jim Rumbaugh, Ivar Jacobson, G. Booch Unified Modeling Language Reference Manual: Addison-Wesley Publishing Co., 1999, 576 p.

[13] B.P. Douglass Real-Time UML. Developing Efficient Objects for Embedded Systems: Addison-Wesley Publishing Co., 1998, 365 p.

[14] G. Booch The Visual Modeling of Software Architecture for the Enterprise. Rose Architect. October 1998, Vol. 1, No 1. p 18-25.

[15] Barker R. CASE Method. Entity-Relationship Modeling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990

[16] Object Management Group, 2003. OMG Unified Modeling Language Specification / www. omg. org.

[17] .http://www.rational.com/uml.

[18] Chonoles M. J., Schardt J.A. UML 2 for Dummies. - Hungry Minds, 2003. - 412 р.

[19] Nock C. Data Access Patterns: Database Interactions in Object-Oriented Applications. - Addison Wesley, 2003. - 512 р.

[20] Fontoura M., Pree W., Rumpe B. UML Profile for Framework Architectures. First edition. Addison Wesley Longman, Inc.,, 2001, 240 pages

[21] Fowler M.,Scott K., UML Distilled Second Edition A Brief Guide to the Standard Object Modeling Language Second Edition, Addison Wesley Longman, Inc., 1999, 224 pages

[22] Gramma E.,Helm R.,Johnson R., Vlissides J. Design Patterns. Elements of reusable object-oriented software. , Addison Wesley Longman, Inc., 1999, 368 pages.

[23] Rebecca M. Riordan, Designing Effective Database Systems, Addison Wesley Professional., Inc., 2005, 384 pages

[24] Thomas A. Pender . UML Weekend Crash Course. Wiley Publising, Inc., 2002, 362 pages

[25] Rebecca M. Riordan, Seeing Data: Designing User Interfaces for Database Systems Using .NET, Addison Wesley Professional., Inc., 2004, 544 pages

[26] Husman H. Loose Semantics for UML/OCL // Society for Design and Process Science, 2002. - P. 32-39.

[27].Genova G., Llorens J., Quintana V. Digging into Use Case Relationships // Lect. Notes Comput. Sci. - 2002. - V. 2460. -P. 115-127.

[28] Kendal S. Fast Track UML 2.0. - Apress, 2004., 416 р.

[29] Gogolla M., Henderson-Sellera B. Analysis of UML Stereotypes within the UML Metamodel // Lect. Notes Comput. Sci. -2002. - V. 2460. - P. 84-99.

Характеристики

Список файлов реферата