Буй Д.Б., доктор фізико-математичних наук, старший науковий співробітник
Шишацька О.В., інженер-програміст, що виконує науково-технічні розробки
Київський національний університет імені Тараса Шевченка
кафедра теорії та технології програмування
Зроблено стислий екскурс в історію виникнення та розвитку UML, наведено короткий огляд мови та зроблено спробу систематизувати велику кількість навчально-наукової літератури, присвяченої цій мові.
Ключові слова: UML, об’єктно-орієнтоване проектування, мова моделювання, специфікація, семантика.
Останнім часом великої популярності набула мова моделювання UML (Unified Modeling Language), яка стала “стандартом де-факто” в області розробки програмного забезпечення та застосовується для розв’язання задач інших галузей, наприклад, бізнес-моделювання. У роботі зроблено стислий екскурс в історію виникнення та розвитку UML, наведено короткий огляд мови та зроблено спробу систематизувати велику кількість навчальної та наукової літератури, присвяченої цій мові.
Виникнення та призначення мови
В основу UML покладено декілька об’єктно-орієнтованих методів, кожен із яких був орієнтований на підтримку окремих етапів об’єктно-орієнтованого аналізу та проектування (ООАП) [1/2/] :
- метод Граді Буча (Grady Booch), що одержав умовну назву Booch або Booch’91, Booch Lite (пізніше – Booch’93) і вважався найбільш ефективним на етапах проектування та розробки різних програмних систем [1, 3];
- метод Джеймса Румбаха (James Rumbaugh), що одержав назву Object Modeling Technique – ОМТ (пізніше – ОМТ-2) та найбільше підходив для аналізу процесів обробки даних в інформаційних системах [4];
- метод Айвара Джекобсона (Ivar Jacobson), Object-Oriented Software Engineering – OOSE, що містив засоби подання варіантів використання, які мають істотне значення на етапі аналізу вимог у процесі проектування бізнес-застосувань [5].
Історія розвитку UML датується 1994 роком, коли почалася уніфікація та інтеграція вищевказаних методів їх авторами. Проект уніфікованого методу (Unified Method) версії 0.8 був опублікований в жовтні 1995 року.
Всі питання розробки та супроводження мови UML сконцентровані в рамках консорціуму OMG (Object Management Group) [6]. Хоча консорціум OMG був утворений з метою розробки пропозицій по стандартизації об’єктних і компонентних технологій CORBA, мова UML набула статусу другого стратегічного напрямку в роботі OMG. В листопаді 1997 року OMG оголосив UML стандартною мовою об’єктно-орієнтованого моделювання і прийняв на себе обов’язки по її подальшому розвитку. Відповідна група фахівців забезпечує публікацію матеріалів, що містять опис наступних версій мови UML і запитів пропозицій RFP (Request For Proposals) по її стандартизації. Статус мови UML визначений як відкритий для всіх пропозицій по її доробці та удосконаленню. В 2003 році опубліковано опис мови UML 2.0, що став результатом роботи над набором запитів RFP 2000 року. В описі наводились: інфраструктура UML [7], мова обмежень об’єктів (Object Constraint Language – OCL) [8], суперструктура UML [9] та формат обміну діаграм [10].
Основними ініціативами консорціуму OMG в рамках роботи над проектом UML є: (1) моделювання систем реального часу; (2) визначення моделі виконання – точної специфікації поведінки моделей, що підтримуються UML, і семантики виконання моделей; (3) обробка даних підприємства (розподілення об’єктної обробки даних підприємства та інтеграція застосувань підприємства) – визначені так звані профілі, що описують способи створення великих розподілених паралельних систем підприємства; (4) визначення процесу розробки програмного забезпечення – специфіковані структури визначення процесів розробки програмного забезпечення; (5) стандарт зберігання даних; (6) співставлення технології CORBA і мови UML; (7) формат XMI (Metadata Interchange) для обміну моделями UML в текстовому форматі [11].
Сама мова UML не є власністю та ніким не запатентована, хоча зазначений вище документ (опис мови в [11]) захищений законом про авторське право. У той же час абревіатура UML, як і деякі інші (наприклад, OMG, CORBA), є торговельною маркою їхніх законних власників.
Існує консорціум партнерів UML, у який увійшли такі всесвітньовідомі компанії, як Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, Unisys та інші. Ці компанії забезпечують підтримку роботи з уточнення визначення нотації, подальшого удосконалення і доповнення мови, а також супроводження розробки інструментальних засобів підтримки мови.
З більш ніж 800 компаній і організацій, що входять до складу консорціуму OMG, особливу роль відіграє Rational Software Corporation [12] – розробник одного з перших інструментальних CASE-засобів Rational Rose 98 [13, 14], у якому реалізована мова UML.
Необхідно відмітити увагу компанії Microsoft до технології, що базується на мові UML (підтримується цією мовою). На основі такої технології Microsoft, Rational Software Corporation та інші постачальники засобів розробки програмних систем створили єдину інформаційну модель, що одержала назву UML Information Model, призначену для подальшого створення стандартного інтерфейсу між засобами розробки застосувань і засобами візуального моделювання.
Слід зазначити, що на даний момент Rational Software Corporation офіційно входить до складу IBM (http://www-306.ibm.com/software/rational/).
Мова UML призначена для розв’язання наступних завдань [15/16/]:
- надати у розпорядження користувачів готову до використання виразну потужну мову візуального моделювання, що дозволяє їм розробляти осмислені моделі й обмінюватися ними;
- передбачити внутрішні механізми розширюваності й спеціалізації для розширення базових концепцій мови;
- забезпечити максимальну незалежність проекту створення програмного забезпечення від конкретних мов програмування (цільових мов програмної реалізації) й процесів розробки;
- забезпечити формальну основу для однозначної інтерпретації цієї мови моделювання (мова повинна бути одночасно точною і доступною для розуміння, без надлишкового формалізму);
- стимулювати розширення ринку об’єктно-орієнтованих інструментальних засобів створення програмного забезпечення;
- інтегрувати кращий практичний досвід щодо використання мови та реалізації програмних засобів її підтримки.
Принципи використання UML специфіковані в Rational Unified Process (RUP) – розвиненої методики створення програмного забезпечення, оформленої у вигляді бази знань, яка фізично розміщена на web (http://www-306.ibm.com/software/awdtools/rup/support/) та оснащена пошуковою системою [17/18/, 19]. Це комерційний продукт Rational Software Corporation, що визначає строгий регламент розподілу задач і відповідальності між виконавцями в процесі розробки програмного забезпечення.
Основними документами з UML є [20], де описано так звану метамодель UML, але дуже мало уваги приділяється саме семантиці мовних конструкцій. Опис поточної версії мови UML [7-10] та приклади розробки програмних систем з використанням CASE-засобу Rational Rose можна знайти на web-вузлі OMG за адресою www.omg.org. Модифікації мови UML і найновіші її версії, котрі лише повинні побачити світ, наводяться на вузлі www.celigent.com/uml.
Зазначимо, що офіційна документація по UML досить важка для розуміння; тому виходить багато книг, котрі описують її з різними акцентами. Наприклад, базова система позначень UML популярно і доступно викладена в книзі Мартіна Фовлера (Martin Fowler) [21/22/], яка вважається одним з найкращих посібників по вивченню мови. Слід відзначити книги, написані головними авторами UML – Г. Бучем, І. Джекобсоном, Д. Рембо (в іншому перекладі Румбахом або Рамбо): в [15] викладено детальну інформацію про використання UML (покриває близько 80% мови) та проілюстровано застосування мови на великій кількості прикладів; в [19] розглядається процес об’єктно-орієнтованої розробки програмного забезпечення; в довіднику з UML [23/24/] охоплюється вся мова та робиться спроба розкрити її змістовну семантику. Початківцям варто звернути увагу на видання [25], що вийшло у серії “… для чайников”; детальний та повний опис мови також наведено в [26].
Питанням використання продукту Rational Rose присвячені праці [27, 28], але найбільш розгорнуто та доступно моделювання систем засобами UML з використанням Rational Rose описано та проілюстровано великою кількістю прикладів в [29/30/] (перевидання [31] – є розширеним та адаптованим під UML 2.0).
Також необхідно виокремити серію книг під редакцією головних авторів мови: “Серія об’єктні технології” видавництва “Addison Wesley”, що розкриває питання застосування мови [17, 32, 33, 34, 35]. Застосуванню UML та шаблонів проектування також присвячені [36, 37].
UML створювалася як мова моделювання загального (універсального) призначення для застосування в таких “дискретних” галузях як програмне забезпечення, апаратні засоби чи цифрова логіка.
В UML наявні структури, що дозволяють фіксувати різноманітні рішення по відображенню (1) функціональності системи [35, 38, 39], (2) динамічної та статичної структури системи, (3) організації елементів системи [40], (4) реалізації системи. Популярності набуває використання UML при проектуванні баз даних [33, 41, 42]. Завдяки відкритості (наявності в мові механізмів розширення) вона надає потужний інструментарій для розв’язання задач інших галузей, наприклад, бізнес-моделювання [44].
Загальна структура мови
Семантика мови UML визначається для двох видів об’єктних моделей: структурних моделей та моделей поведінки. Структурні (статичні) моделі описують структуру сутностей або компонентів системи, включаючи їхні класи, інтерфейси, атрибути та зв’язки. Моделі поведінки (динамічні моделі) описують поведінку або функціонування об’єктів системи, включаючи їхні методи, взаємодію (співробітництво) між ними, а також процес зміни станів окремих компонентів і системи в цілому [3].
Формальний опис мови UML ґрунтується на наступній загальній ієрархічній структурі модельних подань (представлень), яка складається із чотирьох рівнів абстракції: (1) мета-метамодель, (2) метамодель, (3) модель, (4) об’єкти користувача [7].
Рівень мета-метамоделі утворює базову основу для всіх метамодельних подань та визначає мову для специфікації метамоделі. Мета-метамодель визначає модель мови UML на найвищому рівні абстракції (відповідно на найнижчому рівні конкретизації) і є найбільш компактним її описом. Метамодель – екземпляр або конкретизація мета-метамоделі – визначає мову для специфікації моделей. Всі основні поняття мови UML – це поняття рівня метамоделі. Модель у контексті мови UML є екземпляром (конкретизацією) метамоделі в тому розумінні, що будь-яка (конкретна) модель системи повинна використовувати тільки поняття метамоделі, конкретизувавши їх стосовно до даної ситуації. Змістовно кажучи, рівень моделі призначений для опису конкретної предметної області. Конкретизація понять моделі відбувається на рівні об’єктів, які є екземплярами моделі і містять конкретну інформацію щодо відповідності понять моделі та предметної області.
Основою подання UML на метамодельному рівні є опис трьох його логічних блоків (або пакетів за іншою термінологією): основні елементи, елементи поведінки та загальні механізми [9].
Концептуальна модель мови
Концептуальна модель мови включає основні будівельні блоки, правила їх поєднання та деякі загальні для усієї мови механізми [15, 23, 22].
Словник мови UML містить сутності – абстракції, що є основними елементами моделі, та відношення – основні сполучні будівельні блоки. Сутності та відношення за певними правилами поєднуються в конструкції – діаграми.
В UML визначено чотири типи сутностей [15]:
- структурні сутності, які розподіляються на основні сутності, різновиди основних сутностей та решту структурних сутностей; до основних сутностей відносяться: клас (Class), інтерфейс (Interface), кооперація (Collaboration), прецедент (Use case), активний клас (Active class), компонент (Component), вузол (Node); до різновидів основних сутностей відносяться: актор (Actor), сигнал (Signal), утиліта (Utility, утиліти є видами класів); процес (Process) і нитка (Thread, нитки є видами активних класів); до решти відносяться: застосування (Application), документ (Document), файл (File), бібліотека (Library), сторінка (Page) та таблиця (Table, таблиці є видами компонентів);
- сутності поведінки (Behavioral things), до яких відноситься взаємодія (Interaction) та автомат (State machine);
- групуючі сутності, серед яких поки що виділений тільки пакет (Packages);
- анотаційні сутності, серед яких поки що виділена тільки примітка (Note).
Основними типами відношень в UML є відношення: залежності (Dependency), асоціації (Association) (різновидом асоціації є відношення агрегування (Aggregation)), узагальнення (Generalization) та реалізації (Realization). Існують також їх варіації, наприклад, уточнення, трасування, включення та розширення (для залежностей).
Для побудови коректно оформленої моделі в UML визначено правила, що дозволяють коректно і однозначно визначати: (1) імена сутностей, відношень та діаграм, (2) область дії імен (контекст, в якому ім’я має деяке значення), (3) видимість імен (для використання іншими елементами), (4) цілісність (правильність та узгодженість співвідношення елементів), (5) виконання моделі [15].
Ефективність та спрощення застосування мови забезпечується використанням певних угод, так званих, загальних механізмів: специфікацій (Specifications), доповнень (Adornments), прийнятих розподілів (Common divisions) та механізмів розширення (Extensibility mechanisms) [15, 23, 22].
Кожен елемент нотації UML має унікальне графічне позначення та специфікацію – текстове представлення синтаксису та змістовної семантики відповідного будівельного блоку.
Практично усі будівельні блоки характеризуються дихотомією “клас / об’єкт” та “інтерфейс / реалізація”. Це основні підходи поділу реальності при об’єктно-орієнтованому моделюванні систем.
UML допускає контрольовані розширення (тобто є відкритою мовою) для адаптування мови до конкретних потреб. Наявність внутрішніх механізмів розширення принципово відрізняє UML від таких засобів моделювання як IDEF0, IDEF1X, IDEF3, DFD та ERM [43], які є замкненими, тобто не допускають розширення засобами самої мови. До механізмів розширення UML відносяться: (1) стереотип (Stereotype), який розширює словник мови (дозволяє створювати із існуючих блоків нові, специфічні для конкретної розв’язуваної задачі); (2) теговане значення (Tagged value), яке розширює властивості будівельного блоку (дає можливість включати нову інформацію в специфікацію елемента; (3) обмеження (Constraint), яке розширює семантику будівельного блоку (дозволяє додавати нові або модифікувати існуючі правила за допомогою семантичних обмежень текстового вигляду природною мовою або формальною мовою OCL). Деякі розширення набули такої популярності, що були визначені як стандартні елементи поточної версії UML [15, 23, 22].
Графічні конструкції мови
У рамках мови UML всі подання про моделі складної системи фіксуються у вигляді спеціальних графічних конструкцій, що одержали назву діаграм [8]. Діаграма в UML – це графічне представлення набору елементів, зображуване, як правило, у вигляді зв’язного графу з вершинами (сутностями) і ребрами (відношеннями). Теоретично діаграми можуть містити будь-які комбінації сутностей і відношень. Однак на практиці застосовується порівняно невелика кількість типових комбінацій. У мови UML визначені наступні види діаграм:
- діаграма варіантів використання (Use case diagram);
- діаграма класів (Class diagram);
- діаграми поведінки (Behavior diagrams), до яких відносяться діаграма станів (Statechart diagram), діаграма діяльності (Activity diagram), діаграми взаємодії (Interaction diagrams); в свою чергу до діаграм взаємодії відносяться діаграма послідовності (Sequence diagram) та діаграма кооперації (Collaboration diagram);
- діаграми реалізації (Implementation diagrams), до яких відносяться діаграма компонентів (Component diagram) та діаграма розгортання (Deployment diagram).
Перелік цих діаграм і їхніх назв є канонічними, вони – невід’ємна частина графічної нотації мови UML. Більше того, процес ООАП нерозривно пов’язаний із процесом побудови цих діаграм. При цьому сукупність побудованих у такий спосіб діаграм є самодостатньою в тому розумінні, що в них утримується вся інформація, що необхідна для реалізації проекту складної системи.
Кожна із цих діаграм деталізує й конкретизує різні подання про моделі складної системи в термінах мови UML. При цьому діаграма варіантів використання є найбільш загальною концептуальною моделлю складної системи, вихідною (тобто початковою) для побудови всіх інших діаграм. Діаграма класів є, по своїй суті, логічною моделлю, що відбиває статичні аспекти структурної побудови складної системи. Діаграми поведінки також є різновидами логічної моделі, які відбивають динамічні аспекти функціонування складної системи. І, нарешті, діаграми реалізації слугують для подання фізичних компонентів складної системи, й тому відносяться до її фізичної моделі. Таким чином, інтегрована модель складної системи в нотації UML представляється у вигляді сукупності зазначених вище діаграм.
Слід звернути увагу, що при моделюванні системи часто будують діаграму об’єктів (Object diagram), яка представляє множину об’єктів і відношень між ними в заданий момент часу (так званий “знімок системи”). Вона не є канонічною діаграмою UML, але корисна в деталізації системи.
Підходи до специфікації семантики мови
Початковою метою розвитку UML було забезпечення більш точного опису мови моделювання – забезпечення формальної основи для розуміння мови моделювання. Однак до цього часу формальна семантика не є частиною стандарту. Огляд декількох пропозицій щодо визначення такої семантики наведено в [45], де розглянуто теоретико-множинний, трансляційний, метамодельний підходи та запропоновано так звану “вільну” семантику. Слід зазначити, що і в самій специфікації UML існує багато огріхів та протиріч. Так в роботі [46] розглядаються відношення включення та розширення для варіантів використання, в [47] аналізуються стандартні стереотипи метамоделі UML. В роботі [48] пропонується використати RM-ODP (The Reference Model of Open Distributed Processing [49]) для розв’язання проблем мови. Зауважимо, що в специфікації UML модель RM-ODP згадується як структура, що безпосередньо впливає на архітектуру метамоделі мови (розділ “Preface: Relationships to Other Models” [9]). Окрім того RM-ODP використовується в MOF (Meta-Object Facility) для управління типами. В [48] ідентифікуються три проблеми метамоделі UML та пропонуються їх розв’язки на базі RM-ODP:
- структурний хаос семантики мови – “висока технічність, небагатослівність та складність для розуміння новачками”; розв’язання: використання структури RM-ODP та теорії типів Б. Расела;
- відсутність декларативної семантики, суперечливість семантики мови при описі, по-перше, відношень між моделями, побудованими з використанням мови, та, по-друге, безпосередньо суб‘єктів моделювання; розв’язання: реалізація базової концепції моделювання (Basic Modeling Concept);
- недостатнє теоретичне обґрунтування використовуваної метамоделі мови UML; розв’язання: пропонована в статті концепція моделювання на основі RM-ODP, теорії типів Б. Расела та підходу А. Тарського до інтерпретації формальних числень вважається повністю обґрунтованою.
Багато наукових досліджень, присвячених формалізації моделі та метамоделі мови UML, розглядають не саму мову в повному об’ємі, а деяку її підмову (формальну та строго структуровану).
Так, в [50] розглядаються BON (Business Object Notation, об’єктно-орієнтована мова моделювання, що по суті співпадає з підмовою діаграм класів UML [51]) та PVS (Prototype Verification System – мова специфікацій, розроблена для автоматичного аналізу метамоделей мов моделювання [52]). Результатом роботи є повна формальна специфікація метамоделі об’єктно-орієнтованої мови моделювання у формі, придатній до автоматичного аналізу. Однак BON в порівнянні з UML більш формалізована та “підігнана” під умови розв’язуваної задачі. Схожий підхід використаний в роботі [53], де в якості платформи для формалізації мов моделювання вибрано формалізм Boom, що складається з метамоделі і мови формальних специфікацій Odal – простої строго типізованої мови з семантикою, визначеною за допомогою так званого π-числення. В роботі [54] розглядається формалізація мови MML (Metamodelling Language), що є підмножиною UML і запропонована авторами в якості бази для усієї UML 2.0. Формалізація мови MML проводиться за допомогою MML-числення, основою якого є так зване ψ-числення Cardeli і Abadi [55].
Нарешті, в роботі [56] демонструється застосовність алгебраїчного методу для формального опису ER-діаграм (Entity-Relationship diagrams), які є аналогами діаграм класів UML.
Підсумовуючи, мова UML є потужним, гнучким засобом моделювання, з відкритим до вдосконалення описом стандарту. Неоднозначність як деяких конструкцій самої мови, так і поглядів на семантику мови та наявність в її специфікації неформальних описів потребує подальшого розвитку формальної основи для повної та несуперечливої інтерпретації мови.

Список використаних джерел

1. Booch G. Object-oriented analysis and design with applications. Second edition. – The Benjamin/Cummings Publishing Company Inc., 1994. – 589 p.
2. Буч Г. Объектно-ориентированное проектирование с примерами применения: Пер с анг. – Москва: Конкорд, 1996. – 519 с.
3. Буч Г. Объектно-ориентированный анализ и проектирование: с примерами приложений на C++. Пер с анг. – Санкт-Петербург: “Издательство Бином”, “Невский диалект”, 1998. – 560 с.
4. Rumbaugh J., Blacha M., Premerlani W., Eddy F., Lorensen W. Object-Oriented Modeling and Design. – Prentice-Hall Inc., 1991. – 432 р.
5. Jacobson I. Object-Oriented Software Engineering. A Use Case Driven Approach. – Addison-Wesley Publishing Company, 1993. – 547 р.
6. Object Management Group, 2003. OMG Unified Modeling Language Specification / www. omg. org.
7. www.omg.org / 04-10-14pdf.
8. www.omg.org / 05-06-06pdf.
9. www.omg.org / 05-07-04pdf.
10. www.omg.org / 05-06-04pdf.
11. Рамбо Д. Тенденции в развитии языка UML и разработки ПО / http://www.interface.ru/fset.asp?Url=/rational/umltend.htm.
12. http://www.rational.com/uml.
13. Кумсков М. Rational Rose 98 – CASE-продукт нового поколения / http://www.interface.ru/public/rose98/rose98.htm.
14. Новичков А. Rational Rose для разработчиков / http://www.interface.ru/fset.asp?Url=/rational/xros.htm.
15. Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language User Guide. – MA.: Addison-Wesley Publishing Co., 1999. – 512 p.
16. Буч Г., Рамбо Д., Джекобсон А. UML. Руководство пользователя: Пер. c анг. – Москва: ДМК, 2000. – 432 с.
17. Kruchten P. The Rational Unified Process – An Introduction. – MA.: Addison-Wesley, 2000. – 234 p.
18. Кратчен Ф. Введение в Rational Unified Process. – Пер. с англ. – Москва: Издательский дом “Вильямс”, 2003. – 203 с.
19. Jacobson I., Booch G., Rumbaugh J. The Unified Software Development Process. – MA.: Addison-Wesley Publishing Co., 1999. – 512 p.
20. Booch G., Jacobson I, Rumbaugh J. The UML specification documents. – Santa Clara, CA.: Rational Software Corp., 1997. (Специфікацію можна знайти за адресою www. rational.com.)
21. Fowler M., Scott K. UML Distilled. – MA.: Addison-Wesley, 2000. – 472 р.
22. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования.: Пер. с англ. – Москва: Мир, 1999. – 416 с.
23. Rumbaugh J., Jacobson I., Booch G. Unified Modeling Language Reference Manual. – MA.: Addison-Wesley Publishing Co., 1999. – 576 p.
24. Рамбо Д., Якобсон А., Буч Г. UML. Специальный справочник: Пер. c анг. – Санкт-Петербург: Изд. дом “Питер”, 2002. – 654 с.
25. Chonoles M. J., Schardt J.A. UML 2 for Dummies. – Hungry Minds, 2003. – 412 р.
26. Kendal S. Fast Track UML 2.0. – Apress, 2004., 416 р.
27. Трофимов С. А. Практическая работа в Ration Rose / http://ooad.asf.ru/Files.aspx
28. Вендров А. М.. Объектно-ориентированный анализ и проектирование с использованием языка UML и Rational Rose. Практикум / http://ooad.asf.ru/Files.aspx
29. Boggs W., Boggs M. Mastering UML witch Rational Rose. – Sybex Inc., 1999. – 579 p.
30. Боггс У., Боггс М. UML. Rational Rose: Пер.с англ. – Москва: Издательство “Лори”, 2001. – 582 с.
31. Boggs W., Boggs M. UML witch Rational Rose 2.0. – Sybex Inc., 2002. – 702 p.
32. Кватрани Т. Визуальное моделирование с помощью Rational Rose и UML: Пер. с англ. – Москва: Издательский дом “Вильямс”, 2003. – 192 с.
33. Нейбург Э., Максимчук Р. Проектирование баз данных с помощью UML.: Пер. с англ. – Москва: Издательский дом “Вильямс”, 2002. – 288 с.
34. Гома Х. UML. Проектирование систем реального времени, распределенных и параллельных приложений.: Пер. с англ. – Москва: ДМК, 2002. – 704 с.
35. Розенберг Д., Скотт К. Применение объектно-ориентированного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. – Москва: ДМК, 2002. – 160 с.
36. Ларман К. Применение UML и шаблонов проектирования. 2-е издание.: Пер.с англ. – Москва: Издательский дом “Вильямс”. 2004. – 604 с.
37. Gamma E., Helm R., Jonson R., Vissides J. Element of Reusable Object-Orient Software. – Addison Wesley Longman Inc., 1994. – 372 р.
38. Коберн А. Современные методы описания функциональных требований к системам.: Пер. с англ. – Москва: ЛОРИ, 2002. – 262 с.
39. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход.: Пер. с англ. – Москва: “Вильямс”, 2002. – 448 с.
40. Duffy Daniel J. Domain architectures: models and architectures for UML applications. – John Wiley & Sons Ltd, 2004. – 390 р.
41. Мюллер Р. Базы данных и UML. Проектирование.: Пер. с англ. – Москва: ЛОРИ, 2002. – 420 с.
42. Nock C. Data Access Patterns: Database Interactions in Object-Oriented Applications. – Addison Wesley, 2003. – 512 р.
43. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. – Москва: ДИАЛОГ-МИФИ, 2005. – 432 с.
44. Eriksson H.-Erik, Penker M. Business Modeling with UML: Business Patterns at Work. – Wiley Computer Publishing, 2000. – 274 p.
45. Husman H. Loose Semantics for UML/OCL // Society for Design and Process Science, 2002. – P. 32-39.
46. Genova G., Llorens J., Quintana V. Digging into Use Case Relationships // Lect. Notes Comput. Sci. – 2002. – V. 2460. – P. 115–127.
47. Gogolla M., Henderson-Sellera B. Analysis of UML Stereotypes within the UML Metamodel // Lect. Notes Comput. Sci. – 2002. – V. 2460. – P. 84-99.
48. Naumenko A., Wegmann A. A Metamodel for the Unified Modeling Language // Lect. Notes Comput. Sci. – 2002. – V. 2460. – P. 2-17.
49. RM-ODP Open Distributed Processing – Reference Model - ISO, ITU.: ISO/IEC 10746-1, 2, 3, 4 | ITU-T Recommendation X.901, X.902, X.903, X.904, 1995-1998.
50. Paige R., Ostroff J. Metamodelling and Conformance Checking with PVS // Lect. Notes Comput. Sci. – 2001. – V. 2029. – P. 2-16.
51. Walden K., Nerson J.-M. Seamless Object-Oriented Software Development. – Prentice-Hall, 1995.
52. Owre S., Shankar N., Rushby J., Stringer-Calvert D. The PVS Language Reverence Version 2.3 – September, 1999. – (Tech. Rep. / SRI International Technical Report).
53. Overgaard G. Formal Specification of OO Modeling // Lect. Notes Comput. Sci. – 2000. – V. 1783. – P. 193-207.
54. Clark T., Evans A., Kent S. The Metamodelling Language Calculus: Foundation Semantics for UML // Lect. Notes Comput. Sci. – 2001. – V. 2029. – P. 17-31.
55. Cardeli L, Abadi M. A theory of Objects. – Springer-Verlag, 1996.
56. Lellahi K. Conceptual Data Modeling: An Algebraic Viewpoint // Lect. Notes Comput. Sci. – 2001. – V. 2244. – P. 336-348.