Роздрукувати сторінку
Главная \ Методичні вказівки \ Методичні вказівки \ 1696 Лабораторна робота 5 на тему Визначення структури системи прийняття рішень за допомогою об’єктно-орієнтованих CASE-засобів з курсу Управління вимогами в ІТ проектах

Лабораторна робота 5 на тему Визначення структури системи прийняття рішень за допомогою об’єктно-орієнтованих CASE-засобів з курсу Управління вимогами в ІТ проектах

« Назад

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

Визначення структури системи прийняття рішень за допомогою об’єктно-орієнтованих CASE-засобів

Мета роботи:

  • вивчення основних етапів роботи в об’єктно-орієнтованих CASE-засобах

  • вивчення основних елементів нотації

  • вивчення інтерфейсу об’єктно-орієнтованих CASE-засобів і принципів роботи з ними

  • створення нового проекту в в об’єктно-орієнтованих CASE-засобах

1. Етапи проведення моделювання в об’єктно-орієнтованих CASE-засобах

Моделювання проводиться як порівневий спуск від концептуальної моделі до логічної, а потім до фізичної моделі програмної системи.

Концептуальна модель відображається у вигляді діаграм варіантів використання (use-case diagram). Цей тип діаграм служить для проведення ітераційного циклу загальної постановки завдання разом із замовником. Діаграми варіантів використання є основою для досягнення взаєморозуміння між програмістами-професіоналами, які розробляють систему, і замовниками. Усередині кожного прецеденту можуть бути визначені:

  • вкладена діаграма варіантів використання,

  • діаграма взаємодії об'єктів (collaboration diagram),

  • діаграма послідовності взаємодій (sequence diagram),

  • діаграма класів (class diagram),

  • діаграма переходу станів (state diagram).

Логічна модель дозволяє визначити два різні погляди на системи: статичний і динамічний. Статичний підхід відображається діаграмами класів (class diagram). Саме діаграми класів служать основою для генерації програмного коду на цільовій мові програмування. Можливе дуже гнучке налаштування генерації коду, що дозволяє враховувати конкретні угоди (наприклад, по префіксам імен ідентифікаторів), прийняті в команді розробників проекту.

Динамічний підхід описанняується двома типами діаграм:

  • діаграмами взаємодії об'єктів,

  • діаграмами послідовності взаємодій.

У поточній версії Rational Rose ці діаграми не впливають на генерований код, проте фірми-партнери Rational Software застосовують ці діаграми у своїх додатках. Так, діаграми послідовності взаємодій використовуються в пакеті SQA Suite для автоматизованого тестування компонентів, розроблених в Rational Rose. Класи, введені на цих діаграмах, потрапляють в список класів моделі і можуть використовуватися при конструюванні діаграм класів.

Динаміка конкретного класу може бути виражена за допомогою діаграм переходу станів, що визначають модель кінцевого автомата, що описанняує поведінку класу. Кожен стан задається своєю вершиною; визначеним вхідним і вихідним станом, а також умовою переходу зі стану в стан.

Фізична модель задається компонентною діаграмою (component diagram), яка описанняує розподіл реалізації класів по модулях, і діаграмою поставки (deployment diagram).

Після побудови першого / наступного шару статичної моделі з використанням діаграм класів можна провести генерацію коду на цільовій мові програмування. На рівні коду можна ввести нові уточнюючі класи, змінити атрибути і методи класів моделі і потім синхронізувати код і модель, виконавши зворотне проектування, тобто за модифікованим кодом Rational Rose можна побудувати нову логічну модель взаємозв'язку класів між собою. Повторення такої процедури кілька разів називається ітераційним моделюванням (round-trip modeling), що становить основу м'якого і поступового уточнення постановки задачі і узгодження вимог замовника з наявними ресурсами (обчислювальними, тимчасовими, фінансовими і т. п.).

На рис. 1 наведено зовнішній вигляд Rational Rose. 

Рис. 9.1. Головне вікно Rational Rose 

Створення нового проекту в Rational Rose виробляється вибором меню File / New. При цьому створюється кілька порожніх діаграм верхнього рівня: діаграма варіантів використання, діаграма класів та ін Кожну діаграму можна вибрати для редагування, при цьому на інструментальній панелі відображаються елементи, доступні для даного виду діаграм. Вибір типу поточної діаграми виробляється в меню Browse. 

Таблиця 9.1

Описання елементів управління основної панелі інструментів Rational Rose

Елемент управління

Описання

Відповідний пункт меню

 

Створити нову модель

File ->New

 

Відкрити модель

File -> Open

 

Зберегти модель

File- > Save

 

Надрукувати модель

File ->Print

 

Переключення між типами діаграм

Browse -> Diagram.

 

Отримання справки

Help

 

Відкриття вікна для введення коментарів

View ->Documentation

 

Навігація по діаграмі

Browse - > Previous Diagram

 

Масштабування

View -> Zoom

  

2. Кількісне оцінювання діаграм

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

Словник мови UML включає два види будівельних блоків: сутності і відносини. Сутності – це абстракції, які є основними елементами моделі. Відносини пов'язують різні сутності.

Кількісне оцінювання діаграми можна провести за такою формулою: 

де S – оцінка діаграми;  – оцінки для елементів діаграми;  – оцінки для зв'язків на діаграмі; Obj – число об'єктів на діаграмі;  – число типів об'єктів на діаграмі;  – число типів зв'язків на діаграмі.

Якщо діаграма містить велику кількість зв'язків одного типу (наприклад, модель БД), то число і тип зв'язків можна не враховувати і формула розрахунку приводиться до вигляду 

Якщо на діаграмі показані атрибути та операції класів, можна врахувати їх при розрахунку, при цьому оцінка додається до оцінки відповідного класу: 

де  – оцінка операцій і атрибутів для класу; Ор – кількість операцій у класу, Art – число атрибутів у класі.

При цьому враховуються тільки атрибути та операції, відображені на діаграмі.

Далі в табл. 9.2 та 9.3 наводяться оцінки для різних типів елементів і зв'язків. 

Таблиця 9.2

Основні елементи мови UML

Тип елемента

Оцінка для елемента

Клас (class)

5

Інтерфейс (interface)

4

Прецедент (use case)

2

Компонент (component)

4

Вузол (node)

3

Процесор (processor)

2

Взаємодія (interaction)

6

Пакет (package)

4

Стан (state)

4

Примітка (node)

2

Таблиця 9.3

Основні типи зв’язків мови UML

Тип зв’язку

Оцінка для зв’язку

Залежність (dependency)

2

Асоціація (association)

1

Агрегування (aggregation)

2

Композиція (composition)

3

Узагальнення (generalization)

3

Реалізація (realization)

2

Решта типів зв'язків повинні розглядатися як асоціації.

Недоліком діаграми є як занадто низька оцінка (при цьому діаграма недостатньо інформативна), так і занадто висока оцінка (при цьому діаграма зазвичай надто складна для розуміння). У табл. 9.4 наведено діапазони оптимальних оцінок для основних типів діаграм. 

Таблиця 9.4

Діапазон оцінок для діаграм UML

Тип діаграми

Діапазон оцінок

Розгортання (deployment)

2 – 2,5

Послідовності (sequences)

3 – 3,5

Кооперативна (cooperative)

3,5 – 4

Пакетів (package)

3,5 – 4

Стану (state)

2,5 – 3

Нижче наведений приклад оцінки простої діаграми класів за даною методикою.

Діаграма містить три класи без операцій і атрибутів, отже,  = 1,  = 15 і Obj = 3. В якості зв'язків використовуються асоціації, агрегування та узагальнення; отже,  = 6 і  = 3.

Тобто числова оцінка для даної діаграми дорівнює 3,5.

 

3. Приклад

На рис. 9.3 і 9.4 наведені діаграми класів моделі підсистеми «Служба зайнятості в рамках вузу» системи «Дистанційне навчання». Ці діаграми реалізують один і той самий фрагмент підсистеми «Служба зайнятості в рамках вузу», але перша з них більш повно реалізує принципи об'єктно-орієнтованого підходу.

Знайдемо чисельну оцінку для кожної з діаграм.

Діаграма 1

Проведемо розрахунок оцінки атрибутів і операцій для класів «Роботодавець», «БД студентів» та «Студент».

«Роботодавець»: Аналогічно для класу «БД студентів» отримуємо 2,53; для класу «Студент» – 3,33. Розрахуємо повне значення для діаграми.

Діаграма 2

Проведемо розрахунок оцінки атрибутів і операцій для класів «Деканат», «Група» і «Користувач системи». Для класу «Деканат» отримуємо 2,36; для класу «Група» – 3,33; для класу «Користувач системи» –1,11.

Розрахуємо повне значення для діаграми.

У результаті оцінка для діаграми 1 потрапляє в середину оптимального діапазону для діаграм класів, а оцінка для діаграми 2 виявляється нижча оптимального діапазону.

Такий результат можна пояснити наступними причинами:

1. Діаграма 2 містить надмірно деталізований клас «Користувач системи», тоді як у діаграмі 1 він спрощено за допомогою побудови ієрархії класів.

2. Клас «Деканат» на діаграмі 2 бере на себе занадто багато функцій, наслідком чого є надлишок зв'язків.

3. Клас «Бухгалтерія» на діаграмі 2 не відноситься безпосередньо до фрагмента, змодельованого на діаграмі, тобто ускладнює модель, не вносячи при цьому корисної інформації.

 

4. Завдання

1. Створити новий проект в Rational Rose.

2. Додати в проект діаграму класів.

3. Розмістити на ній клас з довільним ім'ям.

4. Редагувати ім'я класу на діаграмі.

5. Додати на діаграму мітку з коментарем.

6. Відкрити специфікацію класу, змінити тип класу.

7. Видалити клас, використовуючи браузер діаграм.

8. Зберегти проект.

5. Контрольні запитання

1. Які три типи моделей використовуються при проектуванні?

2. Яке призначення концептуальної моделі?

3. Назвіть основний вид діаграм в концептуальній моделі.

4. Яке призначення логічної моделі?

5. Назвіть основний вид діаграм в логічній моделі.

6. Назвіть два погляди на модельовану систему в логічній моделі.

7. Яка роль діаграм взаємодії об'єктів у логічній моделі?

8. Яка роль діаграм послідовності взаємодій в логічній моделі?

9. Яке призначення фізичної моделі?

10. Назвіть основний вид діаграм у фізичній моделі.

11. У чому сенс процедури ітераційного моделювання?

З повагою ІЦ "KURSOVIKS"!