1. UML. Визначення, переваги застосування.

2. Компоненти UML та моделі.

3. Дiаграма класiв. Позначення, особливостi застосування.

4. Дiаграма послiдовностей.

5. Види зв’язкiв мiж класами: узагальнення. Навести приклад.

6. Види зв’язкiв мiж класами: асоцiацiї. Навести приклад.

7. Види зв’язкiв мiж класами: агрегацiя. Навести приклад.

8. Види зв’язкiв мiж класами: композицiя. Навести приклад.

9. Елементи дiаграми класiв.

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

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

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

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

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

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

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

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

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

19. Діаграма прецедентiв. Вiдношення розширення.

20. Діаграма станiв.

21. Діаграма дiяльностi.

22. Діаграма компонентів. Компонент. Графічне зображення компонента. Види компонентів.

23. Діаграма компонентів. Інтерфейс. Графічне зображення інтерфейсів. Графічне зображення залежностей.

24. Діаграма компонентів. Елементи діаграми компонентів: вузол, з’єднання, відношення залежності.

25. Оглядова діаграма взаємодії.

26. Діаграма кооперації. Кооперація. Структурні елементи. Рівні кооперації.

27. Архітектура ПЗ. Види підходів. Стандартизований підхід.

28. Об’єктний підхід проектування архітектури ПЗ.

29. Загальносистемний підхід проектування архітектури ПЗ.

30. Мови опису архітектури ПЗ. Види архітектури ПЗ. Базові фреймворки для архітектури ПЗ.

31. Шаблони проектування ПЗ. Твірні шаблони.

32. Шаблони проектування ПЗ. Структурні шаблони.

33. Шаблони проектування ПЗ. Шаблони поведінки.

34. Тестування ПЗ. Види тестування.

35. Тестування ПЗ. Рівні тестування.

36. Модульне тестування.

37. Супровід ПЗ.

Задачі:

1. Розробити UML-діаграму класів згідно Вашої курсової роботи (мінімум 4 класи з усіма видами зв’язків).

2. Розробити UML-діаграму станів згідно Вашої курсової роботи (мінімум 3 стани і 3 події).

3. Розробити UML-діаграму компонентів згідно Вашої курсової роботи (мінімум 4 компонента з усіма видами зв’язків).

1. Uml. Визначення, переваги застосування.

UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, називаної UML-моделлю. UML був створений для визначення, візуалізації, проектування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.

UML може бути застосовано на всіх етапах життєвого циклу аналізу бізнес-систем і розробки прикладних програм. Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.

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

Основною причиною використання мови UML є спілкування розробників між собою.^[1]

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

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

Практично усі CASE-засоби (програми автоматизації процесу аналізу і проектування) мають підтримку UML. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи.

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

UML необхідний:

• керівникам проектів, які керують розподілом завдань і контролем за проектом

• проектувальникам інформаційних систем які розробляють технічні завдання для програмістів;

• бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;

• програмістам які реалізовують модулі інформаційної системи.

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

2. Компоненти uml та моделі.

Оскільки компонент як елемент фізичної реалізації моделі представляє окремий модуль коду, інколи його коментують з вказівкою додаткових графічних символів, що ілюструють конкретні особливості його реалізації. Строго.говоря, ці додаткові позначення для приміток не специфіковані в UML. Проте їх застосування спрощує розуміння діаграми компонентів, істотно підвищуючи наочність фізичного представлення. Деякі з таких загальноприйнятих позначень для компонентів зображені нижче (рис. 10.2). В UML виділяють три види компонентів.     По-перше, компоненти розгортання, які забезпечують безпосереднє виконання системою своїх функцій. Такими компонентами можуть бути спільні бібліотеки з розширенням dll (рис. 10.2, а), Web-сторінки на мові розмітки гіпертексту з розширенням html (рис. 10.2, б) і файли довідки з розширенням ир (рис. 10.2, в).     По-друге, компоненти-робочі продукти. Як правило - це файли з вихідними текстами програм, наприклад, з розширеннями h або срр для мови C + + (рис. 10.2, г).     По-третє, компоненти виконання, що представляють здійснимі модулі - файли з розширенням ехе. Вони позначаються звичайним чином.