Етап формування вимог до системи
Програмний продукт оперує даними про рецепти.
Завдання системи
Система повинна застосовуватися для отримання довідкової інформації про приготування тої чи іншої страви. Призначається для полегшення приготування різних страв.
Загальна характеристика системи
Система повинна виконувати основні функції:
· Можливість виведення всіх рецептів на екран.
· Можливість виведення детальної інформації про вибраний рецепт.
· Можливість пошуку за певними критеріями.
· Можливість зміни даних (додавання, вилучення, редагування).
· Дані про рецепти зберігаються у відповідних текстових файлах.
· Можливість задання під кожен рецепт відповідного зображення.
· Можливість роздруку рецептів.
Умови роботи
Комп’ютерна програма для пошуку потрібного рецепту. Операції з даними про рецепт можуть розширюватись.
Не функціональні вимоги
· Для звичайної роботи програми достатньо комп’ютера з монітором клавіатурою та мишкою.
· Програма повинна без затримок здійснювати пошук.
· Простий і зрозумілий інтерфейс
Користувачі програми
Програма є універсальною, такою, що підходить як для домашнього користування, так і для установ громадського харчування.
Якість
Порівняно з іншими програмними продуктами система пропонує правильну інформацію про рецепти, має можливість швидкого пошуку. Збоїв програми при тестуванні не виявлено.
Продуктивність
Продуктивність системи залежить від швидкості пошуку , який не повинен тривати довше 200-350мсек., швидкості внесенню змін (100мсек).
У випадку використання фіскального принтера на продуктивність системи впливає драйвер пристрою. Для такого випадку потрібно реалізувати драйвер обміну даних системи з принтером який одночасно з запитом видає результат виконання операції. Допускається затримка на виконання операції фіскальним пристроєм не більше ніж 1сек. Збільшення затримки на необхідну кількість часу береться з протоколу самого принтера. Результат операції принтера виводиться на екран або цифрове табло для користувача тоді перевірити і вивести на екран одну з причин несправностей а саме:
· Занижена або завищена напруга
· Внутрішня помилка
· Немає зв’язку з принтером
· Принтер не готовий для виконання операцій
Відношення з іншими програмами.
Система працює на всіх ОС Microsoft Windows починаючи з версії 98.
Ресурси
Для нормальної роботи системи достатньо таких мінімальних засобів як:
Апаратні засоби комп’ютера:
· Процесор 1.7 GHz
· Вінчестер 60 Gb
· Відео карта 256 Mb
· Оперативна пам'ять DDR2 512 Мb 400MHz
Програмні засоби:
· Операційна система Microsoft Windows XP SP2
· Microsoft NET Framework 2.0
· Перевірка вимог.
· Відповідність вимог до мінімальних ресурсів системи
Таблиця1
| Характеристика | Міра |
| Продуктивність | Пошук рецепту повинен відбуватися мінімум як за 200мсек. Час на обробку інформації чеку не повинен перевищувати 1сек. |
| Розмір | Кількість записів обмежена дисковим простором. |
| Зручність для користувача | Час, потрібний для навчання не більший 10 хвилин . Середній час виконання будь-якої операції не більше 30 секунд. |
| Переносимість | Програма працює на всіх операційних системах Microsoft Windows починаючи з Windows98. Для перенесення без інсталяції достатньо перенести систему на новий комп'ютер . |
Підтримка
Часто з’являються нові пристрої з якими система також повинна могти працювати. В такому випадку реалізація обміну і обробки даних між пристроєм та системою має бути в окремій бібліотеці. Це дасть змогу легко змінювати механізм обміну інформації з пристроєм при тому не зачіпаючи функцій самої системи.
2.2 Розробка UML діаграми варіантів використання
Основна мета створення будь-якої програмної системи це створення програмного продукту, який допомагає користувачу виконувати свої повсякденні завдання. Для створення таких програм насамперед визначаються вимоги, яким повинна задовольняти система. Проте якщо дати користувачам написати ці вимоги на папері, то часто можна одержати список функцій, по якому важко судити чи буде майбутня система виконувати своє призначення і чи зможе вона полегшити користувачу виконання його роботи взагалі.
Для того, щоб точніше зрозуміти як повинна працювати система, все частіше використовується опис функціональності системи через варіанти використання (UseCase або прецеденти). Варіанти використання це - опис послідовності дій, які може здійснювати система у відповідь на зовнішні дії користувачів або інших програмних систем. Варіанти використання відображають функціональність системи.
Діаграми варіантів використання описують функціональне призначення системи або те, що система повинна робити. Мета розробки діаграм наступна:
· визначити загальні межі і предметну область;
· сформулювати загальні вимоги до функціональної поведінки проектованої системи;
· розробити початкову концептуальну модель системи її подальшої деталізації у формі логічних і фізичних моделей;
· підготувати початкову документацію для взаємодії розробників системи з замовниками і користувачами.
Діаграма варіантів використання – це граф спеціального вигляду, який є графічною нотацією для представлення конкретних варіантів використання, акторів, можливо деяких інтерфейсів, і відносин між цими елементами. При цьому окремі компоненти діаграми можуть бути поміщені в прямокутник, який позначає проектовану систему в цілому. Слід зазначити, що відносинами даного графа можуть бути тільки деякі фіксовані типи взаємозв'язків між акторами і варіантами використання, які в сукупності описують сервіси або функціональні вимоги до модельованої системи.
Суть діаграми варіантів використання полягає в наступному. Проектована система представляється у вигляді безлічі суті або акторів, що взаємодіють з системою за допомогою варіантів використання. При цьому актором (actor) або дійовою особою називається будь-яка сутність, що взаємодіє з системою ззовні. Це може бути людина, технічний пристрій, програма або будь-яка інша система, яка може служити джерелом дії на модельовану систему так, як визначить сам розробник. Варіант використання служить для опису сервісів, які система надає актору. Діаграма варіантів використання може доповнюватися текстом пояснення, який розкриває сенс або семантику складових її компонентів.
Рис.2. Діаграма варіантів використання.
2.3. Розробка UML діаграм поведінки системи
2.3.1 UML діаграма послідовності
Діаграма послідовності — в UML, діаграма послідовності відображає взаємодії об'єктів впорядкованих за часом. Зокрема, такі діаграми відображають задіяні об'єкти та послідовність відправлених повідомлень.
Діаграми послідовностей - це відмінний засіб документування поведінки системи, деталізації логіки сценаріїв використання, але є ще один спосіб – використовувати діаграми взаємодії. Діаграма взаємодії показує потік повідомлень між об'єктами системи і основні асоціації між ними і по суті, як вже було сказано вище, є альтернативою діаграми послідовностей. Слід зазначити, що використання діаграми послідовностей або діаграми взаємодії - особистий вибір кожного проектувальника і залежить від індивідуального стилю проектування. На позначеннях, що застосовуються на діаграмі взаємодії, думаємо, не варто зупинятися детально. Тут все стандартно: об'єкти позначаються прямокутниками з підкресленими іменами (щоб відрізнити їх від класів), асоціації між об'єктами вказуються у вигляді з'єднувальних ліній, над ними може бути зображена стрілка із зазначенням назви повідомлення та його порядкового номера. Необхідність номеру повідомлення пояснюється дуже просто - на відміну від діаграми послідовностей, час на діаграмі взаємодії не показується у вигляді окремого вимірювання.
Рис.3. Діаграма послідовностей.
Пояснення до рисунка:
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. Вихід з програми.
2.3.2 UML діаграма діяльності
Діаграма діяльності — в UML, візуальне представлення графу діяльностей. Граф діяльностей є різновидом графу станів скінченного автомату, вершинами якого є певні дії, а переходи відбуваються по завершенню дій.
Дія є фундаментальною одиницею визначення поведінки в специфікації. Дія отримує множину вхідних сигналів, та перетворює їх на множину вихідних сигналів. Одна із цих множин, або обидві водночас, можуть бути порожніми. Виконання дії відповідає виконанню окремої дії. Подібно до цього, виконання діяльності є виконанням окремої діяльності, буквально, включно із виконанням тих дій, що містяться в діяльності. Кожна дія в діяльності може виконуватись один, два, або більше разів під час одного виконання діяльності. Щонайменше, дії мають отримувати дані, перетворювати їх та тестувати, деякі дії можуть вимагати певної послідовності. Специфікація діяльності (на вищих рівнях сумісності) може дозволяти виконання декількох (логічних) потоків, та існування механізмів синхронізації для гарантування виконання дій у правильному порядку.
Рис.4. Діаграма діяльності.
2.4. Розробка графічного інтерфейсу програмних засобів комп’ютерної системи
Сучасність досить багата на досягнення в області програмного забезпечення та проектування користувацького інтерфейсу. З новими технологіями проектування інтерфейсу змінилось, але, як і раніше, базується на людському сприйнятті і пізнанні. Проектування користувацького інтерфейсу – це більше, ніж просто розміщення на екрані керуючих елементів програми. З роками користувачі перейшли від інтерфейсів командного рядка до графічних інтерфейсів і зараз відкривають можливості об’єктно-орієнтованого користувацького інтерфейсу. Ідея полягає в тому, що при проектуванні інтерфейсу завжди потрібно думати про перспективи і не забувати, що програмне забезпечення створюється з розрахунку на потреби користувача, а не проектувальника. Проектування і побудова вдалого і практичного користувацького інтерфейсу – це й наука, й мистецтво.
Рис.5. Пояснення дизайну.
На рис.6 показано як виглядають рецепти у вигляді книги.
Рис.6. Головна сторінка.
На рис.7 показано як виглядають рецепти у вигляді списку.
Рис.7. Вікно з змістом.
РОЗДІЛ 3