Докладніше. Елементи діаграми класів

Елементи діаграми класів

Окрім класів на діаграмах класів можуть міститися і деякі інші елементи.

Інтерфейси

Інтерфейси — це абстрактні класи, тобто з них не можна напряму створювати екземпляри. У інтерфейсах можуть міститися операції, але не атрибути. Класи можуть бути нащадками інтерфейсів (за допомогою асоціації реалізації), а з цих діаграм можна потім створювати сутності.

Типи даних

Типи даних — це базові елементи, з яких типово будується мова програмування. Типовими прикладами є цілі числа і булеві значення. Вони не можуть мати зв’язків з класами, але класи можуть мати зв’язки з ними.

Переліки

Переліки є простими списками значень. Типовим прикладом є перелік днів тижня. Пункти переліків називаються літералами переліків. Подібно до типів даних, переліки не можуть мати зв’язків з класами, але класи можуть мати зв’язки з переліками.

Пакунки

Пакункам відповідають простори назв у мовах програмування. На діаграмі пакунки використовуються для позначення частин системи, у яких міститься декілька класів, може навіть сотні класів.

10. Діаграма об'єктів.

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

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

Докладніше

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

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

11. Побудова концептуальної моделi. Визначення та етапи.

Для розуміння UML необхідно засвоїти його концептуальну модель, яка включає в себе три складові частини:
- Основні будівельні блоки мови;
- Правила їх поєднання;
- Деякі загальні для всієї мови механізми.

Словник мови UML включає три види будівельних блоків:
- Сутності;
- Відносини;
- Діаграми.

Сутності - це абстракції, що є основними елементами моделі. Відносини пов'язують різні сутності; діаграми групують представляють інтерес сукупності сутностей.
У UML є чотири типи сутностей:
- Структурні;
- Поведінкові;
- Групуючі;
- Анотаційні.

12. Діаграма пакетiв.

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

13. Діаграма розгортань.

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

14. Унiфiкований процес розробки.

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

Для реалізації вимог замовника у встановлені терміни, уніфікований процес розділяється на фази, які складаються з ітерацій, тому процес ще називають ітеративним. Кожна ітерація проходить цикл основних робіт і наближає розробників до кінцевої мети: створення моделі системи та її програмної реалізації. В ході ітерацій створюються проміжні модулі, які потрібні для успішного завершення проекту і варіант програмної системи, який реалізує деякий набір функцій, що збільшується від ітерації до ітерації. Фази робіт процесу показано нижче:

15. Діаграма прецедентiв. Складовi та вiдношення мiж ними.

Діаграма Прецедентів візуально зображає різноманітні сценарії взаємодії між акторами (користувачами) і прецедентами (випадками використання); описує функціональні аспекти системи (бізнес логіку).

Діаграми Прецедентів відіграють важливу роль не тільки у комунікації між збирачами вимог до проекту і потенційними користувачами. Діаграми Прецедентів дописані бізнес логікою і детальними специфікаціями прецедентів, як джерельна інформація, успішно використовують учасники розробки проекту на всіх його фазах (зародження, дизайн, програмування, тестування, документування..). Добре продумані і завершені специфікації прецедентів легко перевтілюються у Тестові Випадки.

Елементи Діаграми Прецедентів:
o Актор – користувач.
o Прецедент – випадок використання, дія. Позначається овалом.
o Граничні межі системи охоплюють усі випадки використання у системі.
Позначається прямокутником.

Елементи взаємодії Діаграми Прецедентів:
o Використовує – користувач виконує дію.
o Включає – один прецедент використовує іншого.
o Розширює – представлення дочірніх прецедентів.
o Вимагає – наступний прецедент вимагає виконання попереднього.
o Схожий – прецеденти подібні, але описують різну функціональність.
o Рівнозначний - подібна функціональність, але користувач сприймає, як різну.

16. Діаграма прецедентiв. Вiдношення включення.

Діаграма Прецедентів візуально зображає різноманітні сценарії взаємодії між акторами (користувачами) і прецедентами (випадками використання); описує функціональні аспекти системи (бізнес логіку).

Діаграми Прецедентів відіграють важливу роль не тільки у комунікації між збирачами вимог до проекту і потенційними користувачами. Діаграми Прецедентів дописані бізнес логікою і детальними специфікаціями прецедентів, як джерельна інформація, успішно використовують учасники розробки проекту на всіх його фазах (зародження, дизайн, програмування, тестування, документування..). Добре продумані і завершені специфікації прецедентів легко перевтілюються у Тестові Випадки.

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

• Щоб специфікувати місце в потоці подій, де саме базовий прецедент включає поведінку іншого, просто пишеться слово include, за яким іде ім'я прецеденту, що включається.
• Приклад: include(“Перевірити клієнта”).
• На діаграмі прецедентів відношення включення зображують у вигляді залежності зі стереотипом include (пунктирна стрілка спрямована від базового прецеденту до того, що включається, абстрактного).

17. Діаграма прецедентiв. Вiдношення узагальнення.

Діаграма Прецедентів візуально зображає різноманітні сценарії взаємодії між акторами (користувачами) і прецедентами (випадками використання); описує функціональні аспекти системи (бізнес логіку).

Діаграми Прецедентів відіграють важливу роль не тільки у комунікації між збирачами вимог до проекту і потенційними користувачами. Діаграми Прецедентів дописані бізнес логікою і детальними специфікаціями прецедентів, як джерельна інформація, успішно використовують учасники розробки проекту на всіх його фазах (зародження, дизайн, програмування, тестування, документування..). Добре продумані і завершені специфікації прецедентів легко перевтілюються у Тестові Випадки.

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

Відношення узагальнення можуть застосовуватись і між акторами. Це, можливо, більш звично. До того ж, у Rational Rose для специфікації акторів використовується та ж сама форма, що і у випадку класів (тобто актори по суті розглядаються як окремі випадки класів).

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

18. Діаграма прецедентiв. Вiдношення залежностi.

Діаграма Прецедентів візуально зображає різноманітні сценарії взаємодії між акторами (користувачами) і прецедентами (випадками використання); описує функціональні аспекти системи (бізнес логіку).

Діаграми Прецедентів відіграють важливу роль не тільки у комунікації між збирачами вимог до проекту і потенційними користувачами. Діаграми Прецедентів дописані бізнес логікою і детальними специфікаціями прецедентів, як джерельна інформація, успішно використовують учасники розробки проекту на всіх його фазах (зародження, дизайн, програмування, тестування, документування..). Добре продумані і завершені специфікації прецедентів легко перевтілюються у Тестові Випадки.

Дата добавления: 2015-10-21