Реферат: Уніфікована мова моделювання (UML)
· Композитної/складеної структури
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]
У результаті в 1990-е рр. підхід CASE робив порівняно невеликий вплив на розробку комерційного програмного забезпечення, фокусуючись на декількох прикладних областях, наприклад, на обробці викликів у телекомунікаційних системах, де добре підходили подання у вигляді кінцевих автоматів. Навіть там, де CASE-Засоби застосовувалися на практиці, звичайно використовувалася тільки їхня частина, що дозволяє розроблювачам малювати діаграми програмних архитектур і документувати свої рішення, на основі чого програмісти потім вручну робили й розвивали реалізації. Однак, оскільки був відсутній прямий зв'язок між діаграмами й реалізаціями, розроблювачі не прагнули до великої точності діаграм, оскільки вони рідко синхронізувалися із кодом на подальших стадіях проектів.
В останні двадцять років досягнення в області мов програмування й платформ привели до підвищення рівня абстракцій, доступних для розроблювачів, зм'якшивши один з недоліків підходу CASE. Наприклад, сьогодні розроблювачі звичайно використовують більше виразні об’єктно-орієнтовані мови (зокрема, C++, Java і C#), а не Fortran або C. Повторно використовувані бібліотеки класів і платформи підтримки додатків мінімізують потребу у винаході загальних і прикладних сервісів - транзакцій, відмовостійкості, оповіщення про події, безпеку, розподіленого керування ресурсами й т.д. Все це дозволяє розроблювачам краще захиститися від складності, пов'язаної зі створенням додатків на основі традиційних технологій.[14]
Незважаючи на ці досягнення, залишається кілька неприємних проблем. У центрі цих проблем лежить складність платформ, що росте швидше здатності мов загального призначення маскувати її. Наприклад, популярні платформи проміжного програмного забезпечення J2EE, .NET і CORBA містять тисячі класів і методів з багатьма складними залежностями й тонкими побічними ефектами, що вимагає значних зусиль при програмуванні й ретельному настроюванні.
Родинна проблема полягає в тому, що код більшості додатків і платформ як і раніше пишеться на мовах третього покоління, для чого потрібно багато часу й зусиль, особливо для виконання інтеграційних дій - розгортання, конфігурування й підтримка якості системи. Наприклад, на Java або C# важко написати код, коректно й оптимально розгортає великомасштабної розподіленої системи із сотнями тисяч взаємозалежних компонентів.