46.Пояснити, у яких випадках використовують діаграми станів об'єкту?
Нею визначаються:
- умови переходів (застереження - guards on transitions)
- переходи, зумовлені певними подіями;
- дії при переході;
- дії при вході в стан;
- діяльність, яка триває доти, доки стан є активним;
- дії при виході зі стану;
- вставка станів;
- паралельно діючі стани.
Можуть виділятися суперстани та підстани. Вони разом із вкладеними станами дозволяють конструювати ієрархію станів системи. У даному разі подія - це назва переходу. Події можуть мати аргументи, які визначають список даних, що передаються з переходом (такі, як помилка коду або моніторинг значення). Застереження визначає умови, які потрібно виконати для здійснення переходу. Нарешті список операцій визначає деякий список функцій разом з їхніми аргументами, котрі буде викликано як результат цього переходу
47.Описати процес формування і аналізу вимог.
Вимоги – це властивості, якими повинно володіти ПЗ для адекватного виконання функцій, сюди входять умови, обмеження на середовище і техніку. Вимоги відображають потреби замовника, виконавця, розробника. Вимоги: програмні, які відображають вимоги до процесу, до ОС, до режиму виконання ПЗ, функціональні(призначення системи), нефункціональні (умови виконання ПЗ), системні(описують вимоги до програмної системи).
Процес формування вимог проходить через декілька етапів:
аналіз наочної області(аналітика);
збір вимог;
класифікація вимог;
вирішення протиріч;
призначення пріоритетів;
перевірка вимог.
Існують 3 підходи до формування вимог:
метод, оснований на використанні опорних точок зору;
метод сценаріїв;
етнографічний метод.
Найбільш використовуваним методом є метод опорних точок зору.
Згідно цього методу ми визначаємо різні точки зору на проблему. Точка зору, в основному, розглядатиметься як джерело інформації про системні дані. Точки зору є зовнішніми щодо системи, вони допомагають визначити дані, які необхідні для виконання системних сервісів.
Метод опорних точок зору ще називають методом VORD.
Основні етапи методу VORD:
ідентифікація точок зору, які отримують системні сервіси, та ідентифікація системних сервісів, які відповідають кожній точці зору;
структуризація точок зору, тобто побудова їх ієрархії (загально-системні сервіси, які надаються вищим рівням успадковується нижчими рівнями);
документування опорних точок зору;
відтворення системи точок зору, яка показує об’єкти, що визначаютьсяна основі інформації в опорних точках зору.
Аналіз вимог полягає в визначенні потреб та умов, які висуваються щодо нового , чи зміненого продукту, враховуючи можливо конфліктні вимоги різних замовників.
Аналіз вимог включає три види діяльності:
виявлення вимог;
аналіз вимог(виявлення недоліків вимог – неточностей, неповноти, неоднозначностей – і їх виправлення);
запис вимог ( документування вимог в різних формах – опис звичайною мовою або специфікаціями процесу).
Пояснити, що розуміють під діаграмою компонентів? Яку інформацію вона містить? У яких випадках доцільно будувати діаграми компонентів?
Діаграма компонент — в UML, діаграма, на якій відображаються компоненти, залежності та зв'язки між ними.
Діаграма компонент відображає залежності між компонентами програмного забезпечення, включаючи компоненти вихідних кодів, бінарні компоненти, та компоненти, що можуть виконуватись. Модуль програмного забезпечення може бути представлено в якості компоненти. Деякі компоненти існують під час компіляції, деякі — під час компоновки, а деякі під час роботи програми.
Діаграма компонент відображає лише структурні характеристики, для відображення окремих екземплярів компонент слід використовувати діаграму розгортування.
Діаграми компонентів доцільно будувати, коли ми маємо справу з зв’язком типу «клієнт-сервер».
При використанні діаграми компонент щоб показати внутрішню структуру компонента, клієнтські та серверні інтерфейси можуть утворювати пряме з'єднання з внутрішніми. Таке з'єднання називається з'єднанням делегації.
Приклад:
