(1) імена сутностей, відносин і діаграм,
(2) область дії імен (контекст, у якому ім'я має деяке значення),
(3) видимість імен (для використання іншими елементами),
(4) цілісність (правильність і погодженість співвідношення елементів),
(5) виконання моделі [13].
Ефективність і спрощення застосування мови забезпечується використанням певних угод, так званих, загальних механізмів:
- специфікацій (Specifications),
- доповнень (Adornments),
- прийнятих розподілів (Common divisions
- механізмів розширення (Extensibility mechanisms) [7, 17, 18].
Кожний елемент нотації UML має унікальне графічне позначення й специфікацію - текстове подання синтаксису й змістовної семантики відповідного будівельного блоку.
Практично всі будівельні блоки характеризуються дихотомією “клас/ об'єкт” і“інтерфейс / реалізація”. Це основні підходи розподілу реальності при об’єктно-орієнтованом моделюванні систем.
UML допускає контрольовані розширення для адаптації мови до конкретних потреб. Наявність внутрішніх механізмів розширення принципово відрізняє UML від таких засобів моделювання як IDEF0, IDEF1X, IDEF3, DFD і ERM [37], що є замкнутими й не допускають расширення засобами самої мови.
До механізмів розширення UML ставляться:
- стереотип (Stereotype), що розширює словник мови (дозволяє створювати з існуючих блоків нові, специфічні для конкретного розв'язуваного завдання);
- тег-значення (Tagged value), що розширює властивості будівельного блоку (дає можливість включати нову інформацію в специфікацію елемента);
У нотації UML всі представлення про моделі складної системи фіксуються у вигляді спеціальних графічних конструкцій, що одержали назву діаграм [16]. Діаграма в UML - це графічне подання набору елементів, зображуване, як правило, у вигляді зв'язного графа з вершинами (сутностями) і ребрами (відносинами). Теоретично діаграми можуть містити будь-які комбінації сутностей і відносин. Однак на практиці застосовується невелика кількість типових комбінацій.
В UML використовуються наступні види діаграм (для виключення неоднозначності приведу також позначення англійською мовою):
| Structure Diagrams:· Class diagram· Component diagram· Composite structure diagramo Collaboration (UML2.0)· Deployment diagram· Object diagram· Package diagramBehavior Diagrams:· Activity diagram· State Machine diagram· Use case diagram· Interaction Diagrams:o Communication diagram (UML2.0) / Collaboration (UML1.x)o Interaction overview diagram (UML2.0)o Sequence diagramo Timing diagram (UML2.0) | Структурні діаграми:· Класів· Компонентів· Композитної/складеної структуриo Кооперації (UML2.0)· Розгортання· Об'єктів· ПакетівДіаграми поводження:· Діяльності· Станів· Варіантів використання· Діаграми взаємодії:o Комунікації (UML2.0) / Кооперації (UML1.x)o Огляду взаємодії (UML2.0)o Послідовностіo Синхронізації (UML2.0) |
Підвидом діаграм композитної структури є діаграми кооперації (Collaboration diagram, уведені в UML 2.0), які показують ролі й взаємодія класів у рамках кооперації. Кооперації зручні при моделюванні шаблонов проектування.
Діаграми композитної структури можуть використовуватися разом з діаграмами класів.
Діаграми діяльності використовуються при моделюванні бізнес-процесів, технологічних процесів, послідовних і паралельних обчислень.
Аналогом діаграм діяльності є схеми алгоритмів.
Кінцевий автомат (State machine) — специфікація послідовності станів, через які проходить об'єкт або взаємодія у відповідь на події свого життя, а також відповідні дії об'єкта на ці події. Кінцевий автомат прикріплений до вихідного елемента (класу, кооперації або методу) і служить для визначення поведінки його екземплярів.[40]
Діаграма комунікації (Communication diagram) (в UML 1.x — діаграма кооперації, collaboration diagram) — діаграма, на якій зображуються взаємодії між частинами композитної структури або ролями кооперації. На відміну від діаграми послідовності, на діаграмі комунікації явно вказуються відносини між елементами (об'єктами), а час як окремий вимір не використовується (застосовуються порядкові номери викликів).
Діаграма послідовності (Sequence diagram) — діаграма, на якій зображене впорядковане в часі взаємодія об'єктів. Зокрема, на ній зображуються об'єкти, що беруть участь у взаємодії, і послідовність повідомлень, якими вони обмінюються.
4. Керована моделями інженерія. Огляд
Останні п'ятдесят років дослідники й розроблювачі програмного забезпечення створюють абстракції, що допомагають їм програмувати в термінах цілей свого проекту, а не використовуваного комп'ютерного середовища, і захищаючі їх від складностей цього середовища. Із самого початку ці абстракції включали технології мов програмування й операційних систем. Наприклад, ранні мови програмування (мови асемблера й Fortran) захищали розроблювачів від складностей програмування в машинних кодах. [10.1]
Аналогічно, ранні операційні системи захищали їх від складностей програмування прямо на рівні апаратури. Хоча ці ранні мови й платформи підвищували рівень абстракції, вони явно були "орієнтованими на обчислення". Зокрема, вони забезпечували абстракції простору рішень (тобто області самих комп'ютерних технологій), а не абстракції, що дозволяють звістки розробку в термінах прикладної області. Згодом уживали численні спроби подальшого підвищення рівня абстракції. [14]
Одним з найбільш відомих напрямків, що утворилися в 1980-е рр., є інженерія програмного забезпечення з комп'ютерною підтримкою (Computer-Aided Software Engineering, CASE), що забезпечує методи й засоби розробки програмного забезпечення, що дозволяють розроблювачам виражати свої конструкції з використання графічних програмних засобів загального призначення, різного виду діаграм. Однієї із цілей CASE-Засобів було забезпечення більше ретельного аналізу графічних програм за рахунок їхньої меншої складності, чим у програм, представлених на традиційних мовах програмування (наприклад, у графічних програмах неможливі помилки, що приводять до ушкодження пам'яті).
Іншою проблемою підходу CASE була його нездатність масштабуватися до складних, виробничих систем у широкому діапазоні прикладних областей. Загалом кажучи, CASE-Засобу не підтримували паралельну розробку; на їхній основі можна було розробляти програми поодинці або групою, члени якої по черзі зверталися до файлів, використовуваним цими засобами. [10/1]