Загальні принципи побудови моделі в Rational Rose, Різне, Бази даних, статті

А. Корсачев


Мета даної статті – Описати загальні принципи побудови діаграм Rational Rose (далі RR), їх призначення і зв’язок діаграм між собою. Запропонований підхід досить простий в розумінні й дозволяє представити для чого і як будувати діаграми RR.


Припустимо, що нам доручено провести аналіз бізнес-процесів у замовника і на основі даного аналізу побудувати модель інформаційної системи (ІС). Ми повинні провести аналіз документообігу, склад документів, ролі відповідальних осіб (Actors) і т.д. Завдання це не проста і вимагає значних аналітичних зусиль і досвіду. Результатом цієї роботи має бути список ролей в компанії замовника, чітке розуміння процесу і список об’єктів (сутностей), що беруть участь в цьому процесі. Все це і повинно знайти відображення в діаграмах RR. Крім того, ми разом із замовником повинні скласти список вимог до ІС.



Загальний підхід такий: використовуємо Use case diagram для
відображення списку операцій, які повинна виконувати наша система; інакше кажучи, це вимоги до системи. Кожен Use case – Це певний процес (Послідовність дій), тому ми повинні використовувати Sequence diagram
для його деталізації. На цій діаграмі ми відображаємо об’єкти з предметної області (об’єкти, що беруть участь у бізнес-процесі); таким чином, ми отримуємо екземпляри деяких класів та їх взаємодія. Sequence diagram відображає сам процес, статична картина взаємодії об’єктів відображається за допомогою
Class diagram. Переходимо до Class diagram, На якій зображуються класи нашої ІВ. Далі класи поєднуються в компоненти, які відображаються на Component diagram, Де показується залежність компонентів між собою. На Deployment diagram відображається розміщення цих компонентів по комп’ютерах (вузлах мережі) для проектованої ІС.


От і все, тобто, ми рухаємося від Use case diagram –> Sequence
diagram –> Class diagram
–> Component diagram –>
Deployment diagram.
Цей набір діаграм повинен бути присутнім завжди в моделях RR, інші типи діаграм нам знадобляться для більшої деталізації нашої моделі.


Але давайте більш докладно. Отже, ми має список вимог до ІС складений за допомогою Requisite (R Pro. скласти такий список дуже просто: відкриваєте проект в Requisite (R Pro (Project -> Open) і вибираєте в меню команду Document -> New. Відкривається документ MS Word, де Ви в табличному вигляді (думаю так краще) формуєте список вимог (з контекстного меню вибираєте “Create Requirement … “для кожного вимоги).


Почнемо створювати діаграму прецедентів – Use case diagram. На Use
case diagram
відображаємо взаємодія між ролями (акторами) і прецедентами (Тобто це випадки використання ІС). Наприклад, фраза “Замовник формує замовлення на доставку товару “приводить нас до розуміння наступного: Актор -” Замовник “, прецедент – “Сформувати замовлення на доставку” (прецедент зазвичай починається з дієслова), вимога до системи – “ІС повинна підтримувати операцію формування замовлення на доставку “(список вимог раніше сформований). Тепер необхідно зобразити всіх акторів і ті дії, які вони можуть виконувати (тобто прецеденти) на одній або декількох Use case diagrams, а потім зв’язати кожен прецедент з вимогою, раніше сформованому в Requisite (R Pro (використовуйте контекстне меню на Use case: Requirement Properties –> Associate…).


Прецедент – це певний процес, в якому зазвичай беруть участь кілька об’єктів, тобто “Сформувати замовлення на доставку” передбачає деяку послідовність операцій: відкрити бланк замовлення -> заповнити реквізити замовника -> заповнити тип і кількість товару -> відправити замовлення на виконання (або скасувати замовлення або ще щось). Ось цей процес ми і повинні відобразити на Sequence diagram.
На цих діаграмах ліворуч завжди зображують одного Actor, далі стоять послідовно об’єкти (або асоційовані з ними класи), а стрілками відображається передача повідомлення (або виклик методу класу).


Наприклад, передача повідомлення “Відкрити бланк замовлення” відображається у вигляді стрілки від актора “ЗАМОВНИК” до об’єкта “ЗАМОВЛЕННЯ” з відповідним записом на діаграмі. Відразу зауважимо, що при переході на Class diagram ми створимо клас COrder c методом NewOrder () для даного повідомлення.


Загалом, проведений нами аналіз бізнес-процесів у замовника повинен відобразитися в діаграмних послідовностях дій – Sequence diagrams. Ми може створити цю діаграму для кожного прецеденту (Open Specifications -> Diagrams -> Insert Sequence diagram) або загальну на групу прецедентів (New -> Sequence diagram). Побудувати Collaboration diagrams (Діаграми взаємодій) досить просто по Sequence diagrams (Вони також деталізують процес взаємодії, але не представляють його в часі): Browse -> Create Collaboration diagram (F5). Маючи набір Sequence diagrams, ми можемо переходити до проектування класів і побудови діаграм класів, які представляють статичну картину взаємодії об’єктів.


Ми повинні для кожного об’єкта створити клас, в якому буде реалізовано поведінку цього об’єкта через методи класу. Кожен об’єкт в Sequence diagram повинен бути асоційований з класом: відкрийте специфікацію об’єкта і вкажіть клас, потім для кожного повідомлення на Sequence diagram замініть його ім’я на ім’я методу з класу. Для перевірки моделі виконайте Tolls -> Check Model.


Побудова діаграм класів (Class diagrams) Є найважливішим і трудомістким етапом в створенні моделі. Зрозуміло, що поведінка об’єкта не можливо вбудувати в один клас, тому необхідно створювати діаграми класів, встановлюючи зв’язку між класами. Кожен клас має набір методів (Operations) і змінних (Attributes). В UML прийнято кілька типів зв’язків (відносин) між класами, причому їх назва та інтерпретація відрізняються від прийнятих в ООП, але коротко їх можна описати так:



Association – Семантична зв’язок між класами, показує передачу повідомлень між класами, при генерації коду у визначення класу додається змінна класу, на який спрямована асоціація;



Dependency – Показує залежність одного класу від визначень в іншому класі, наприклад, коли один клас використовується як параметр в описі методів іншого класу, при генерації коду не вносить змін в опис класу;



Aggregation – Зв’язок між цілим і його частинами, при генерації коду у визначення класу додається змінна іншого класу, що є частиною;



Generalization – Зв’язок успадкування між класами, відповідає поняттю спадкування класів в ООП;


За діаграмі класів ми можемо провести генерацію проекту (набору, наприклад, . H і. Cpp-файлів), при цьому важливо налаштувати властивості класу, які впливають на кодогенерацію (вкладки “C + +”, “MSVC” та інші). Зрозуміло, що імплементації методів ніякої не буде, тільки їх визначення.


Маючи набір класів, ми може перейти до формування компонентів ІС – фізичні модулі ІС (DLL, EXE та інші модулі). Залежності між компонентів показуються на Component diagram. Кожен компонент асоційований з одним або декількома класами, які і визначають вміст компонента.


Далі відкрийте специфікацію компонента і на вкладці “Realizes” призначте класи для даного компонента (з контекстного меню “Assign”), а також на вкладці “General” вкажіть мову програмування (тепер специфікація класів доповниться новими вкладками, що впливають на кодогенерацію для даної мови програмування).


Deployment diagram (Діаграма розгортання) побудувати досить просто, тому що вона не містять прив’язки до компонентів в моделі RR, тобто не обов’язково будувати цю діаграму на останньому етапі проектування. На цій діаграмі зображуються комп’ютери (Processor) і зв’язки між ними. Щоб відобразити завдання, які виконуються на цих комп’ютерах (вузлах мережі) відкрийте специфікацію і на вкладці “Detail” для поля “Processes” введіть імена завдань, які можуть відповідати іменам компонентів проектованої ІС.


Процес побудова моделі завершений. Виконаємо перевірку моделі за допомогою команди Tolls -> Check Model і подивимося результати в Log вікні. Якщо помилок немає, можна переходити до генерації проекту і іпмплементаціі ІВ.


Процес побудови моделі носить ітераційний характер. Неможливо побудувати модель відразу, часто необхідно повертатися на інші рівні представлення інформації, вносити зміни, деталізувати і знову повертатися на рівень імплементації (Діаграми класів рівня генерації коду). До того ж ІС схильна постійному зміни (причини вам відомі), тому і код ІВ і її модель повинні змінюватися злагоджено і відповідати один одному.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*