Уніфікована мова моделювання (UML) (стр. 2 из 6)

(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), що розширює властивості будівельного блоку (дає можливість включати нову інформацію в специфікацію елемента);

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

Діаграми

У нотації 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)

Діаграма класів (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) розуміється специфікація поводження, що виконується, у вигляді координованого послідовного й паралельного виконання підлеглих елементів - вкладених видів діяльності й окремих дійhttp://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA ( 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]

4. Керована моделями інженерія. Огляд

Останні п'ятдесят років дослідники й розроблювачі програмного забезпечення створюють абстракції, що допомагають їм програмувати в термінах цілей свого проекту, а не використовуваного комп'ютерного середовища, і захищаючі їх від складностей цього середовища. Із самого початку ці абстракції включали технології мов програмування й операційних систем. Наприклад, ранні мови програмування (мови асемблера й Fortran) захищали розроблювачів від складностей програмування в машинних кодах. [10.1]

Аналогічно, ранні операційні системи захищали їх від складностей програмування прямо на рівні апаратури. Хоча ці ранні мови й платформи підвищували рівень абстракції, вони явно були "орієнтованими на обчислення". Зокрема, вони забезпечували абстракції простору рішень (тобто області самих комп'ютерних технологій), а не абстракції, що дозволяють звістки розробку в термінах прикладної області. Згодом уживали численні спроби подальшого підвищення рівня абстракції. [14]

Одним з найбільш відомих напрямків, що утворилися в 1980-е рр., є інженерія програмного забезпечення з комп'ютерною підтримкою (Computer-Aided Software Engineering, CASE), що забезпечує методи й засоби розробки програмного забезпечення, що дозволяють розроблювачам виражати свої конструкції з використання графічних програмних засобів загального призначення, різного виду діаграм. Однієї із цілей CASE-Засобів було забезпечення більше ретельного аналізу графічних програм за рахунок їхньої меншої складності, чим у програм, представлених на традиційних мовах програмування (наприклад, у графічних програмах неможливі помилки, що приводять до ушкодження пам'яті).

Іншою проблемою підходу CASE була його нездатність масштабуватися до складних, виробничих систем у широкому діапазоні прикладних областей. Загалом кажучи, CASE-Засобу не підтримували паралельну розробку; на їхній основі можна було розробляти програми поодинці або групою, члени якої по черзі зверталися до файлів, використовуваним цими засобами. [10/1]