Типи перехресть

Позначення	Назва	Зміт у випадку злиття стрілок (Fan-in Junction)	Зміт у випадку розгалуження стрілок (Fan-out Junction)
	Asynchronous AND	Всі попередні процеси повинні бути завершені	Всі наступні процеси повинні бути запущені
	Synchronous AND	Всі попередні процеси завершені одночасно	Всі наступні процеси запускаються одночасно
	Asynchronous OR	Один або декілька попередніх процесів повинні бути завершені	Один або декілька наступних процесів повинні бути запущені
	Synchronous OR	Один або декілька попередніх процесів завершено одночасно	Один або декілька наступних процесів запускаються одночасно
	XOR (Exclusive OR)	Тільки один попередній процес завершений	Тільки один наступний процес запускається

Типи об’єктів посилань

Тип об’єкта посилання	Мета опису
OBJECT	Описує участь важливого об’єкта в роботі
GOTO	Інструмент циклічного переходу (у послідовності робіт, що повторюється), можливо на поточній діаграмі, але не обов’язково. Якщо всі роботи циклу присутні на поточній діаграмі, цикл може також зображатися стрілкою, що повертається на стартову роботу. GOTO може посилатися на перехрестя.
UOB (Unit of behaviour)	Застосовується, коли необхідно підкреслити множинне використання будь-якої роботи, але без циклу. Наприклад, робота "Контроль якості" може бути використана в процесі "Виготовлення виробу" декілька разів після кожної одиничної операції. Звичайно цей тип посилання не використовується для моделювання робіт, які запускаються автоматично.
NOTE	Використовується для документування важливої інформації, що відноситься до будь-яких графічних об’єктів на діаграмі. NOTE є альтернативою внесенню текстового об’єкту до діаграми.
ELAB (Elaboration)	Використовується для вдосконалення графіків або їх детальнішого опису. Звичайно вживається для детального опису розгалуження і злиття стрілок на перехрестях.

Білет 12

Завдання: Моделювання даних. Відображення моделі даних в інструментальному засобі Erwin. Створення логічної моделі даних.

Моделюва́ння да́них (англ. Data modeling) — це процес створення моделі даних для інформаційна система з застосуванням формальних підходів.

Відображення моделі даних в інструментальному засобі Erwin:

Створення логічної моделі даних – логічна модель даних складається із:

1. Сутності – таблиці позначаються прямокутником, містять атрибути, об’єкти.

2. Атрибути – це властивості екземпляра сутності. Є атрибут «Первинний ключ» - це унікальна властивість екземпляра сутності (об’єкта).

Білет 13

Завдання: Концепція методу UML. Метод UML (Unified Modelling Language — уніфікована мова моделювання).Види діаграм.

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

2. Агрегація – полягає в тому, що час існування об’єкта частини збігається з часом існування об’єкта цілого.

3. Наслідування – створюється від попереднього існуючого.

4. Узагальнення – створення певної форми від деяких певних частин.

5. Альтернативна асоціація – це коли клас одночасно перебуває в зв’язку тільки з одним елементом певної множини класів.

6. Залежність – коли клас використовує певні операції іншого класу.

Види діаграм:

1. Діаграма послідовності – показує взаємодію об’єктів.

2. Діаграма станів – послідовність діяльності для отримання результату.

3. Діаграма активності (діяльності) - показує поведінку системи, як роботи, які виконує актор (людина). Роботи показують кружечками, які з’єднуються стрілками.

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

5. Діаграма класів — статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення.

Білет 14

Завдання: Метод UML. Діаграми послідовності.

Діаграма послідовності – показують взаємодію об’єктів.

Кожному об’єкту ставиться лінія життя, тобто скільки він буде існувати, вона показується вертикальною лінією. Вгорі лінії стоїть прямокутник з іменем об’єкта. Справа зображується об’єкт, що відноситься до зовнішнього середовища.

Білет 15

Завдання: Метод UML. Діаграми співробітництва.

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

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

Білет 16

Завдання: Метод UML. Діаграми активності.

Діаграма діяльності — в UML, візуальне представлення графу діяльностей. Граф діяльностей є різновидом графу станів скінченного автомату, вершинами якого є певні дії, а переходи відбуваються по завершенню дій.[1]

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

Білет 17

Завдання: Метод UML. Діаграми станів.

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

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

Білет 17

Завдання: Метод UML. Діаграми станів.

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

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

Білет 18

Завдання: Метод UML. Діаграми класів.

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

Білет 19

Завдання: Інженерія вимог як процес. Збирання вимог. Аналіз вимог. Види вимог.

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

Збирання вимог:

Це етап збирання вимог, тут збираються задачі, завдання.

Як збирати вимоги:

1. Брати інтерв’ю у замовника і працівників.

2. Спостерігати за роботою системи.

3. Фіксувати алгоритм роботу усіх випадків використання системи.

Аналіз вимог:

Спочатку треба зробити класифікацію вимог і розділити за критерієм:

1. Функціональні вимоги – те, що робить система.

2. Не функціональні вимоги – це обмеження системи (Це вимоги до швидкодії, мови програмування і т.д.).

3. Зворотні вимоги – те, що програма не повинна робити, того чого не повинно бути.

Види вимог:

1. Бізнес-вимоги — визначають призначення ПЗ, можуть описуватися в документі про бачення (англ. vision) та документі промежі проекту (англ. scope).

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

3. Функціональні вимоги — визначають «що» повинен робити програмний продукт. Ці вимоги описуються в документіСпецифікації програмного забезпечення (англ. SRS).