Розробка програмного комплексу системи «Електронна книга рецептів»

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

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

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

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

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

Пояснення до рисунка:

1. Запит на виведення всіх страв з книги рецептів.
2. Отримання даних про всі рецепти.
3. Обробка даних (отримання даних з БД або з файлів).
4. Отримання результату.
5. Запит на формування змісту книги рецептів.
6. Отримання назв рецептів.
7. Обробка даних (отримання переліку рецептів з книги рецептів).
8. Отримання результату.
9. Запит на пошук та виведення інформації про вибраний рецепт.
10. Отримання даних про рецепт з БД.
11. Обробка даних (отримання даних про певний рецепт).
12. Отримання результатів.
13. Передача результату (результату пошуку).
14. Виведення інформації на роздрук.
15. Обробка даних.
16. Підтвердження роздруку.
17. Запит на пошук даних за певним критерієм.
18. Запит на отримання даних згідно з критеріями пошуку.
19. Обробка даних.
20. Отримання результатів.
21. Виведення списку назв рецептів що відповідають заданому критерію пошуку.
22. Запит на отримання даних про вибраний користувачем рецепт.
23. Обробка даних.
24. Отримання результату.
25. Виведення інформації на роздрук.
26. Обробка даних.
27. Підтвердження роздруку.
28. Вихід з програми.

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

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

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

 

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