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

⇐ ПредыдущаяСтр 5 из 11Следующая ⇒

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 (діаграми компонент).

Дата добавления: 2018-05-13; просмотров: 571; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 1 2 3 456 7 8 9 10 Следующая ⇒

Мы поможем в написании ваших работ!