Діаграма кооперації

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

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

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

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

Розроблені діаграми приведені в додатку А.

3.4. Розробка специфікації вимог

Специфікація вимог до програмного забезпечення (англ. Software Requirements Specification (SRS)) - специфікація вимог для програмної системи - це повний опис поведінки системи що розробляється. Вона включає множину прецедентів, які описують всі взаємодії, які користувачі мають з програмним забезпеченням. Прецеденти також відомі як функціональні вимоги. На додачу до прецедентів SRS також включає нефункціональні (чи додаткові) вимоги. Нефункціональні вимоги є вимогами які накладають обмеження на проект, чи реалізацію (такі як вимоги інженерії продуктивності, стандарти якості, чи обмеження проектування).

Функціональні вимоги (Functional Requirements) описують внутрішню роботу системи, її поведінку: калькулювання даних, маніпулювання даними, опрацьовування даних, і інші специфічні функції які повинна виконувати система.

Нефункціональні вимоги (Non-Functional Requirements) можна поділити на дві категорії: покращення (безпека, надійність, швидкодія, зручність у використанні та інші) та вдосконалення (маштабування, відновлюваність та інші) властивостей системи.

Тобто функціональні вимоги визначають, що система повинна робити, а не функціональні вимоги визначають, якою система повинна бути.

Кожна специфікація складається з загального плану вимог до ПЗ. Розробляти специфікацію рекомендовано посилаючись на стандарт ІЕЕЕ-830-1998. На його підставі багатьма розробниками створено шаблони SRS, зокрема популярним є шаблон розроблений вченим К. Вігерсом.

Специфікація вимог до ПЗ для автоматизації обліку музейних експонатів складається з таких частин:

1. Вступ;

Він складається з таких розділів:

• Мета;

• Визначення, акроніми, скорочення;

• Посилання;

• Короткий зміст;

2. Огляд системи:

• Огляд прецедентів;

• Припущення і залежності;

3. Опис вимог:

• Короткі описи варіантів використання;

• Повні описи варіантів використання;

• Спеціальні вимоги:

До яких входять:

• Функціональність;

• Застосовність;

• Надійність;

• Продуктивність;

• Придатність до експлуатації;

• Обмеження проектування;

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

Результатом опису всіх складових специфікації є готова специфікація до проектованого ПЗ (Додаток Б).