- •Iм. Олеся Гончара
- •Реферат
- •1. Літературний огляд Сучасні технології об'єктно-орієнтованого аналізу та проектування інформаційних систем
- •Введення
- •1.1. Методологія об'єктно-орієнтованого програмування
- •1.2. Методологія об'єктно-орієнтованого аналізу і проектування
- •2. Постановка завдання
- •3. Теоретична частина Визначення візуального моделювання програмного забезпечення
- •3.1. Аналіз та проектування
- •3.2. Візуальне моделювання. Історія мови uml
- •3.3. Структура мови uml
- •3.4. Навчальний приклад. Постановка завдання
- •3.5. Візуальний опис функціональної моделі засобами uml
- •Узагальнення (успадкування)
- •4. Практична частина
- •4.1. Використання uml в проектуванні пз
- •4.2. Загальна характеристика case-засобів Visual Paradigm
- •4.3. Інтерфейс програми vp-uml
- •Головне меню програми
- •Стандартна панель інструментів
- •Вікно браузера
- •Спеціальна панель інструментів
- •Вікно діаграми
- •Вікно документації
- •4.4 Принцип роботи в vp-uml
- •4.5. Лабораторний практикум
- •4.5.1.Лабораторная робота № 1 «Діаграма прецедентів»
- •Приклад виконання лабораторної роботи
- •4.5.2. Лабораторна робота № 2 «Діаграми класів»
- •Типові прийоми моделювання
- •Моделювання логічної схеми бази даних
- •Моделювання словника системи
- •Приклад виконання лабораторної роботи.
- •4.5.3. Лабораторна робота № 3 «Діаграма послідовності».
- •Приклад виконання лабораторної роботи.
- •4.5.4. Лабораторна робота № 4 «Діаграма комунікацій»
- •Висновок
- •Література
3.5. Візуальний опис функціональної моделі засобами uml
Програмна система не функціонує сама по собі. Програмна система функціонує під впливом акторів (Actor) - користувачів, машин та інших програм. При цьому актор очікує, що система поводиться строго певним чином. Актор впливає - система видає очікуваний результат. У випадку, якщо очікуваного результату немає, вимоги користувача не задоволені з усіма витікаючими звідси результатами. Таким чином, актор в UML - людина, машина чи програма, впливає на систему, є зовнішнім по відношенню до неї. Модель того, як вплив призводить до результату, називається Варіантом використання (Use case). Актори і варіанти використання мають спеціальні позначення в UML:
Актори і варіанти використання спілкуються за допомогою посилки повідомлень. Повідомлення можуть йти в обидві сторони. Стрілка показує ініціатора спілкування (актор на малюнку) і може бути опущена.
Виділимо акторів і варіанти використання в розглянутому раніше прикладі з системою бронювання квитків (SRS). Аналіз постановки задачі показує наявність у системи двох акторів: «Користувач» і «Адміністратор». Визначимося з варіантами використання. Необхідно зазначити, що вибір акторів і варіантів використання до деякої міри умовний і може відрізнятися у різних фахівців з аналізу та проектування. Прийняті проектні рішення визначають подальший вибір архітектури системи і суттєво впливають на успіх всього процесу розробки. При цьому «хороших" варіантів може бути декілька.
Перелік Варіантів використання для нашої задачі може бути, наприклад, таким:
- Забронювати квиток.
- Підібрати рейс.
- Працювати з даними.
- Керувати рейсами.
- Працювати з БД аеропорту.
Для візуального представлення акторів, варіантів використання і відносин між ними в UML передбачена спеціальна діаграма - діаграма варіантів використання. Нижче приведена діаграма для розглянутого прикладу:
Наведемо деякі додаткові міркування [3]:
- При такому моделюванні звертають увагу на поведінку системи, а не на її реалізацію.
- Хороша модель описує основну поведінку системи, не будучи надто детальним.
- Подібна модель дозволяє перевірити, чи задовольнить система вимоги замовника.
- Система середніх розмірів може бути описана великою кількістю варіантів використання.
- Варіанти використання можуть описуватися різними сценаріями.
На останньому пункті зупинимося докладніше. Очевидно, назва варіанту використання не дає повного уявлення про те, як він втілюється в життя. Для опису сценарію роботи варіанту використання UML містить спеціальні засоби. Основне з них - діаграма дії.
Діаграма дії це блок-схема, яка відображає динаміку в поведінці системи. Зауважимо, що ця діаграма може використовуватися не тільки для опису сценаріїв Варіанта використання.
Наведемо приклад відповідної діаграми для варіанту використання Бронювання квитків в системі SRS.
3.6. Структура системи та її опис засобами UML
У даному розділі розглядаються елементи UML, призначені для опису структури проектованої програмної системи. Для стандартних понять, відомих з курсу ООП, ми наводимо тільки позначення. Для інших перш за все даємо визначення і коротку характеристику.
Класи
Позначення модифікаторів доступа:
+ |
public |
# |
protected |
- |
private |
Шаблони класів
Об’єкти
Інтерфейси
Визначимося з тим, що ми в даному випадку розуміємо під Інтерфейсом.
Інтерфейс визначає межу між специфікацією того, що робить абстракція, і реалізацією того, як вона це робить [3].
Інтерфейс - це набір операцій, які використовуються для специфицирования послуг, що надаються класом або компонентом [3].
Сенс використання Інтерфейсу складається у відділенні деталей реалізації від функціональності. Так, клас, підсистема, компонент зазвичай надають деяку функціональність, якою можуть користуватися інші класи, підсистеми, компоненти. Опис цієї, доступною ззовні, функціональності міститься в інтерфейсі.
У багатьох мовах програмування поняття Інтерфейс включено в об'єктну модель, що відповідає відбивається на синтаксисі (Object Pascal, Java та ін.) С + +, на жаль, не містить поняття Інтерфейс, тому Інтерфейси моделюються за допомогою використання класів.
Пакети
Пакет - структурна одиниця для групування елементів моделі, зокрема, класів.
Пакет - це спосіб організації елементів моделі в більш великі блоки, якими згодом дозволяється маніпулювати як єдиним цілим. Добре спроектований пакет групує семантично близькі елементи, які мають тенденцію змінюватися разом [3].
Підсистеми
На етапі проектування системи класи і пакети можуть об'єднуватися в підсистеми. Підсистема - структурна одиниця. Кожна підсистема мають свою область відповідальності і реалізує деяку функціональність. Підсистема реалізує Інтерфейс, який описує її поведінку. У даному навчальному прикладі SRS прикладами підсистем є: підсистема бронювання квитків; підсистема доступу до даних ...
Компоненти
Компонент - фізична замінна частина системи, сумісна з одним набором інтерфейсів і забезпечує реалізацію будь-якого іншого [3]. Компонент може розроблятися і тестуватися незалежно від системи.
Види компонентів:
- Вихідні файли (. cpp,. h,. java ...).
- Бінарні файли (. dll,. ocx ...).
- Виконувані файли (. exe).
За змістом компонент являє собою реалізацію підсистеми. На етапі проектування ми працюємо з підсистемами. На етапі реалізації - з компонентами.
Коментарі
UML передбачає можливість написання коментарів (нотаток). Робиться це в такий спосіб:
Відносини між елементами моделі
UML підтримує наступні види відносин між елементами моделі:
- Залежність.
- Асоціація.
- Узагальнення (успадкування).
- Реалізація (для Інтерфейсу).
Відносини показують наявність зв'язків між елементами моделі та семантику цих зв'язків.
Розглянемо кожен з цих типів відносин.
Залежність
Залежність - зв'язок між сутностями (класами, об'єктами). Залежність показує, що зміни в одній сутності можуть вплинути на іншу сутність. Залежність - не структурна зв'язок. Виникає через локальну, глобальну змінні або параметр методу.
TFirst зависит от TSecond
Асоціація
Асоціація - зв'язок між сутностями (класами, об'єктами). Асоціація показує наявність структурної зв'язку між екземплярами (об'єктами). Структурна зв'язок реалізується через поле класу. У позначеннях UML напрямок може бути не вказано (двосторонній зв'язок).
TFirst содержит поле, связанное с TSecond
Напрямок та навігація
Зауважимо, що наявність напряму пов'язано з поняттям Навігація. Навігація означає, що в напрямку стрілки один об'єкт «бачить» інший, в той час як зворотне не виконується.
TFirst бачить TSecond
Кратність
Кратність - спосіб конкретизації характеру відносини. Показує тип відносини 1:1, 1:M, N:1, N:M.
Кожному контейнеру відповідає M елементів. Кожному елементу відповідає 1 контейнер.
Вид кратности |
Значення |
* або 0..* |
≥0 |
1..* |
≥1 |
|
Звичайно 0 або 1 |
|
Дорівнює 1 |
3,5..6 |
{3,5,6} |
Окремі випадки асоціацій: агрегація і композиція
Агрегація припускає, що 0 або більше об'єктів одного типу включені в 1 або більше об'єктів іншого типу.
Композиція - варіант агрегації, в якому кожен об'єкт другого типу може бути включений рівно в 1 об'єкт першого типу.
Композиція
Агрегація