Структура звіту з лабораторної роботи № 3

1. Титульна сторінка (див. Додаток А)

2. Тема, мета, завдання.

3. Копії екранів з результатами виконання завдання 1.

4. Результати виконання завдання 2.

5. Висновок.

Основні запитання

1. Основні характеристики діаграми потоків даних.

2. Класифікація вимог.

3. Що означає процес формулювання вимог?

4. Основні підходи до формулювання вимог.

Варіанти завдань до лабораторних робіт № 3 та №4

1. Модель страхування

2. Створення BPwin-моделі для інформаційної системи «Авіа-каса»

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. Будівництво будинку

29. Випуск номера газети

30. Продаж автомобіля

31. Пошиття одягу

32. Виготовлення меблів

Лабораторна робота № 4

Тема:Дослідження особливостей проектування ПЗ

Мета:Дослідити особливості проектування ПЗ

Завдання:

Відповідно до умови варіанта побудувати UML-діаграми:

- діаграму прецедентів;

- діаграму активності;

- діаграму послідовностей дій

- діаграму класів згідно з варіантом.

Теоретичні відомості

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

По-перше, на даний час все більше ПЗ створюється в режимі офшорного аутсорсинта (передача процесу розробки ПЗ в інші країни, з дешевою робочою силою, наприклад, Ін­дію, Малайзію, Україну, Росію та ін.). По-друге, вважається хорошим тоном розміщення «проб­ної» безкоштовної версії на сайті розробника. По-третє, програма матиме комерційний успіх, якщо вона розроблена швидко. Тому масштабні програмні продукти створюються великими колектива­ми, і виникає необхідність в координації і управлінні процесами розробки ПЗ.

Стандартом де-факто в цій області сьогодні є RUP (Rational Unified Process), для якого є відповідний інструментарій, зокрема Open Source: написано безліч документів і керівництв, а також існує величезна кількість прикладів успішного застосування цієї методики на практиці. Проте як насправді розробляється ПО в компаніях, які орієнтовані на індустріальний ринок? На першому етапі відбувається заключення контракту, головною метою цього етапу є отримання ТЗ (технічно­го завдання) і оцінки вартості проекту (кількість строчок коду). ТЗ, як правило, проектується за допомогою діаграм прецедентів (UseCases) в UML-нотації замовником. Далі відбувається моделювання і уточнення ТЗ також за допомогою UML. Наступний етап - аналіз і проектування -також базується на UML (створюється набір візуальних діаграм, який повністю описує всю логіку роботи майбутнього ПЗ) і є самим складним і відповідальним, так як помилки які були допущенні при проектуванні можуть бути виявлені на етапі тестування вже готового продукту. Наступний етап - це реалізація. На цьому етапі відбувається безпосередній «кодпнг» ПЗ за допомогою, на­приклад. C++. Java або С# на основі розробленого проекту і моделі. Даний етап не є складним і відповідальним, так як вже побудована модель, є проект і все зводиться до кодування необхідних дій. Наступний етап - тестування, на цьому етапі завдання тестувальника - якомога повніше ви­явити приховані проблеми ПЗ, його недоліки, незручності і ін. Тут також використовується діаг­рами прецедентів в UML-нотації. які показують, що, як і в якій послідовності необхідно проводити тестування практично готового ПЗ. Наступний етап - впровадження та установка, для великого і складного ПЗ (наприклад. ERP-системи. для керування бізнес-процесами великих підприємств) також можуть використовуватись діаграми розгортання UML, які показують, що і в якій послідов­ності необхідно робити для розгортання великих програмних продуктів. Етапи експлуатації і під­тримки, супровід та виведення з експлуатаціїтакож можуть базуватися на діаграмах UML. Так що ж таке UML? В найбільш простому випадку діаграму UML можна побудувати за допомогою олівця та клаптика паперу або використовуючи спеціальні продукти, наприклад, Rational Rose (IBM), Poseidon, Thorn та ін. Дамо означення UML.

UML - це мова для специфікації, візуалізації, конструю­вання і документування артефактів програмних систем, а та­кож процесів бізнесу і інших непрограмних систем. Відразу сконцентруємо увагу на переліку "обов'язків" UML. Специфі­кація, візуалізація, конструювання і документування - все це має безпосереднє відношення до високорівневого проектування:

-UML як метод використовується для вивчення поведінки систем:

-UML як мова використовується для "вичленення" знань про предметну область;

-UML як моделююча мова використовується для розуміння (і, можливо, формалізації) закономір­ностей функціонування систем:

-UML як уніфікована мова використовується для координації діяльності розробників.

І нарешті, відразу виключимо можливі неправильні тлумачення: UML не є ні візуальною мо­вою програмування (що означає - на ньому не можна писати виконуваних програм), ні інструмен­том (а, швидше, специфікацією набору правил), ні процесом проектування/конструювання (але, можливо, поглядом на ці процеси).

Rational Rose - могутній CASE-засібо для проектування програмних систем будь-якої складності. Однією із переваг цього програмного продукту є можливість використання діаграм на мові UML. Можна сказати, що Rational Rose є графічним редактором UML діаграм.

У розпорядження проектувальника системи Rational Rose надає наступні типи діаграм, послідовне створення яких дозволяє отримати повне уявлення про всю проектовану систему і про окремі її компоненти:

· Use case diagram (діаграми прецедентів);

· Deployment diagram (діаграми топології);

· Statechart diagram (діаграми станів);

· Activity diagram (діаграми активності);

· Interaction diagram (діаграми взаємодії);

o Sequence diagram (діаграми послідовностей дій);

o Collaboration diagram (діаграми співпраці);

· Class diagram (діаграми класів);

· Component diagram (діаграми компонент).