Реферат: Уніфікована мова моделювання (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# важко написати код, коректно й оптимально розгортає великомасштабної розподіленої системи із сотнями тисяч взаємозалежних компонентів.

К-во Просмотров: 331
Бесплатно скачать Реферат: Уніфікована мова моделювання (UML)