Концептуальна модель мови

Загальна структура мови

Семантика мови UML визначається для двох видів об'єктних моделей:

– структурних;

– поведінкових.

Структурні (статичні) моделі описують структуру сутностей або компонентів системи, включаючи їхні класи, інтерфейси, атрибути й зв'язки.

Моделі поводження (динамічні) описують поведінку або функціонування об'єктів системи, включаючи їхні методи, взаємодію (співробітництво) між ними, а також процес зміни станів окремих компонентів і системи в цілому.

Формальний опис мови UML ґрунтується на наступній загальній ієрархічній структурі модельних подань, що складається із чотирьох рівнів абстракції:

– позначка-метамодель,

– метамодель,

– модель,

– об'єкти користувача.

Рівень метаметамоделі утворить базову основу для всіх метамодельних представлень і визначає мову для специфікації метамоделі.

Позначка-Метамодель визначає модель мови UML на найвищому рівні абстракції (відповідно на найнижчому рівні конкретизації) і є найбільш компактним його описом.

Метамодель – екземпляр або конкретизація позначка-метамоделі – визначає мову для специфікації моделей. Всі основні поняття мови UML – це поняття рівня метамоделі.

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

Конкретизація понять моделі відбувається на рівні об'єктів, які є екземплярами моделі й містять конкретну інформацію про предметну область відповідно до поняттями моделі.

Основою представлення UML на метамодельному рівні є опис трьох його логічних блоків (пакетів):

– основні елементи,

– елементи поводження

– загальні механізми.

Концептуальна модель мови включає основні будівельні блоки, правила їхні сполучення й загальні механізми [13, 17, 18].

Словник мови UML містить сутності (абстракції, що є основними елементами моделі) і відносини (основні сполучні будівельні блоки), Сутності й відносини за певними правилами з'єднуються в конструкції – діаграми.

UML допускає контрольовані розширення для адаптації мови до конкретних потреб. Наявність внутрішніх механізмів розширення принципово відрізняє UML від таких засобів моделювання як IDEF0, IDEF1X, IDEF3, DFD і ERM, що є замкнутими й не допускають розширення засобами самої мови.

До механізмів розширення UML відносяться:

– стереотип (Stereotype), що розширює словник мови (дозволяє створювати з існуючих блоків нові, специфічні для конкретного розв'язуваного завдання);

– тег-значення (Tagged value), що розширює властивості будівельного блоку (дає можливість включати нову інформацію в специфікацію елемента);

– обмеження (Constraint), що розширює семантику будівельного блоку (дозволяє додавати нові або модифікувати існуючі правила за допомогою семантичних обмежень, заданих природною мовою або формальною мовою OCL). Деякі розширення придбали таку популярність, що були внесені в стандарт поточної версії UML [7, 21, 18].

Діаграми

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

В UML використовуються наступні види діаграм:

Структурні діаграми:

– Класів.

– Компонентів.

– Композитної/складеної структури.

§ Кооперації (UML2.0).

– Розгортання.

– Об'єктів.

– Пакетів.

Діаграми поводження:

– Діяльності.

– Станів.

– Варіантів використання.

Діаграми взаємодії:

– Комунікації (UML2.0) / Кооперації (UML1.x).

– Огляду взаємодії (UML2.0).

– Послідовності.

– Синхронізації (UML2.0).

Діаграма класів (Class diagram) – статична структурна діаграма, що описує структуру системи, вона демонструє класи системи, їхні атрибути, методи й залежності між класами.

Діаграма компонентів ( Component diagram) – статична структурна діаграма, показує розбивку програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. Як фізичні компоненти можуть виступати файли, бібліотеки, модулі, що виконуються файли, пакети й т.п.

Діаграма композитної/складеної структури ( Composite structure diagram) – статична структурна діаграма, демонструє внутрішню структуру класів і, по можливості, взаємодію елементів (частин) внутрішньої структури класу.

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

Діаграми композитної структури можуть використовуватися разом з діаграмами класів.

Діаграма розгортання (Deployment diagram) – служить для моделювання працюючих вузлів (апаратних засобів, node) і артефактів, розгорнутих на них. В UML 2.0 на вузлах розвертаються артефакти (англ. artifact), у той час як в UML 1.0 на вузлах розверталися компоненти. Між артефактом і логічним елементом (компонентом), що він реалізує, установлюється залежність маніфестації.

Діаграма об'єктів ( Object diagram) – демонструє повний або частковий знімок моделируємої системи в заданий момент часу. На діаграмі об'єктів відображаються екземпляри класів (об'єкти) системи із вказівкою поточних значень їхніх атрибутів і зв'язків між об'єктами.

Діаграма пакетів (Package diagram) – структурна діаграма, основним змістом якої є пакети й відносини між ними. Твердого поділу між різними структурними діаграмами не проводиться, тому дана назва пропонується винятково для зручності й не має семантичного значення (пакети й діаграми пакетів можуть бути присутнім на інших структурних діаграмах). Діаграми пакетів служать, у першу чергу, для організації елементів у групи по якій-небудь ознаці з метою спрощення структури й організації роботи з моделлю системи.

Діаграма діяльності (Activity diagram) – діаграма, на якій показане розкладання деякої діяльності на її складові частини. Під діяльністю (activity) розуміється специфікація поводження, що виконується, у вигляді координованого послідовного й паралельного виконання підлеглих елементів – вкладених видів діяльності й окремих дій (action), з'єднаних між собою потоками, які йдуть від виходів одного вузла до входів іншого.

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

Аналогом діаграм діяльності є схеми алгоритмів.

Діаграма автомата (State Machine diagram) (діаграма кінцевого автомата, діаграма станів) – діаграма, на якій представлений кінцевийавтомат із простими станами, переходами й композитними станами.

Кінцевий автомат (State machine) – специфікація послідовностістанів, через які проходить об'єкт або взаємодія у відповідь на події свогожиття, а також відповідні дії об'єкта на ці події. Кінцевий автомат прикріплений до вихідного елемента (класу, кооперації або методу) і служить для визначення поведінки його екземплярів.[40]

Діаграма прецедентів ( Use case diagram) (діаграма варіантів використання) – діаграма, на якій відбиті відносини, що існують між акторами і прецедентами.

Основне завдання – являти собою єдиний засіб, що дає можливість замовникові, кінцевому користувачеві й розроблювачеві спільно обговорювати функціональність і поводження системи.

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

Діаграма комунікації (Communication diagram) (в UML 1.x – діаграма кооперації, collaboration diagram) – діаграма, на якій зображуються взаємодії між частинами композитної структури або ролями кооперації. На відміну від діаграми послідовності, на діаграмі комунікації явно вказуються відносини між елементами (об'єктами), а час як окремий вимір не використовується (застосовуються порядкові номери викликів).

Діаграма послідовності (Sequence diagram) – діаграма, на якій зображене впорядковане в часі взаємодія об'єктів. Зокрема, на ній зображуються об'єкти, що беруть участь у взаємодії, і послідовність повідомлень, якими вони обмінюються.

Діаграма огляду взаємодії (Interaction overview diagram) – різновид діаграми діяльності, що включає фрагменти діаграми послідовності й конструкції потоку керування.

Діаграма синхронізації ( Timing diagram) – альтернативне подання діаграми послідовності, що явно показує зміни стану на лінії життя із заданою шкалою часу. Може бути корисна в додатках реального часу.[15,40]

6. Недоліки й переваги UML

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

– Надмірність мови. 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]

Дата добавления: 2014-01-07