Класи та діаграма класів в Rational Rose

Інформація про навчальний заклад

ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
КН
Кафедра:
Кафедра програмного забезпечення

Інформація про роботу

Рік:
2008
Тип роботи:
Лабораторна робота
Предмет:
Інші

Частина тексту файла (без зображень, графіків і формул):

Міністерство освіти і науки України Національний університет "Львівська Політехніка" Кафедра Програмного Забезпечення Лабораторна робота №3 з курсу: «Основи проектування інформаційних систем» на тему: «Класи та діаграма класів в Rational Rose» Львів 2008 Варіант №14 Мета роботи: Ознайомитися з основними поняттями, які використовуються при роботі з класами, а саме: клас, об’єкт, стан, поведінка, індивідуальність, пакет. Ознайомитися з принципами і прийомами побудови діаграми класів за допомогою програмного засобу Rational Rose. Навчитися застосовувати на практиці знання таких понять як клас, об’єкт, пакет, стереотип класу для побудови діаграм класів. Теоретичні відомості. Поняття об’єкту Об’єкт (object) – деяка сутність реального світу або концептуальна сутність. Об’єкт може бути чимось конкретним, наприклад грузовик або мій комп’ютер, або концептуальним, як, наприклад, хімічний процес, банківська операція, торгове замовлення, діловий договір і т.д. Об’єктом називається концепція, абстракція або річ з чітко визначеними границями і значенням для системи. Кожний об’єкт в системі має три характеристики: стан, поведінка, індивідуальність. Стан, поведінка, індивідуальність Станом (state) об’єкту називається одна з умов, в яких він може знаходитись. Стан системи зазвичай змінюється з часом і визначається набором властивостей, які називаються атрибутами (attribute), значень властивостей і відношень між об’єктами. Наприклад, об’єкт навчальний курс (CourseOffering) в системі реєстрації навчальних курсів може знаходитися в одному з двох станів: відкритий для запису або закритий для запису. Якщо кількість студентів, що зареєструвалися на курс, менша ніж дев’ять, то запис на курс продовжується. Після реєстрації дев’ятого студента вона припиняється. Поведінка (behavior) визначає те, як об’єкт реагує на запити інших об’єктів і що може робити сам об’єкт. Поведінка реалізується за допомогою набору операцій (operation) для об’єкту. В системі реєстрації курсів об’єкт навчальний курс може мати операції добавити студента і видалити студента. Індивідуальність (identity) означає, що кожний об’єкт унікальний, навіть якщо його стан є ідентичний стану іншого об’єкта. Наприклад Алгебра 101, секція 1 і Алгебра 101, секція 2 – два об’єкти в системі реєстрації курсів. Хоча кожен із них є навчальним курсом, кожен із них є унікальним. В мові UML об’єкт зображується у вигляді прямокутника, а його ім’я пишеться з підкресленням. Поняття класу Клас (class) – це опис групи об’єктів з спільними властивостями (атрибутами), поведінкою (операціями), відношеннями з іншими об’єктами і семантикою. Таким чином, клас представляє собою шаблон для створення об’єкту. Кожний об’єкт є екземпляром конкретного класу і не може бути екземпляром декількох класів. Наприклад, клас навчальний курс (CourseOffering) може визначатися наступними характеристиками: Атрибути – місце занять, час занять; Операції – отримати місце занять, отримати час занять, додати студента на курс. Алгебра 101, секція 1 і Алгебра 101, секція 2 – це об’єкти, які належать до класу навчальний курс. Кожний об’єкт має значення атрибутів і доступ до операцій, які визначені класом навчальний курс. «Хороший» клас являє собою одну і тільки одну абстракцію, тобто повинен відображати одну основну сутність. Наприклад, клас, що зберігає інформацію про студентів і дані про курси, які студент відвідує протягом декількох років, не є «хорошим» класом тому, що не представляє тільки одну сутність. Такий клас треба розділити на два пов’язаних класи: студент і історія студента. Назви класів обираються у відповідності до понять предметної області. Ім’я повинно бути іменником в однині, який найбільш точно характеризує предмет. В мові UML класи зображають у вигляді розділених прямокутників. В верхній секції вказується ім’я класу, середня секція містить його структуру – атрибути, а нижня описує його поведінку – операції. Порядок створення класів в програмі Rational Rose: Клікніть правою кнопкою миші по розділі Logical View (Логічне представлення) у вікні оглядача. В контекстно-залежному меню, що з’явилося, оберіть команду New→Class (Створити→Клас). У список оглядача буде добавлено новий клас з ім’ям New Class. Введіть потрібне ім’я класу. Стереотипи і класи Про стереотипи вже згадувалось при розгляді діаграми випадків використання. Класи теж можуть мати стереотипи. Як і раніше, стереотип використовується для створення нового типу елементу моделювання, в даному випадку для створення нових типів класів. Деякі основні стереотипи класу – сутність, граничний елемент, елемент управління, сервісний елемент і виключення. Стереотип класу вказується під його ім’ям і береться в подвійні лапки. В програмі Rational Rose є зображення для стереотипів Rational Unified Process – управляючого елементу, сутності і граничного елементу. Виявлення класів Рецептів для знаходження класів не існує. Насправді це дійсно важко. З причини того, що процес аналізу і проектування ітеративний, то список класів з часом змінюється. Початковий набір класів скоріш за все буде відрізнятися від кінцевого. Тому для опису початкового набору класів, виявлених в системі, часто використовують термін «клас-кандидат». Класи-сутності Клас-сутність (entity class) використовується для моделювання даних і поведінки з довгим життєвим циклом. Цей тип класів може представляти сутності реального світу або внутрішні елементи системи. Такі класи зазвичай не залежать від оточення, тобто вони нечутливі до взаємодії зовнішнього середовища з системою. Відповідно, вони не залежать від програми і можуть застосовуватися в різних програмах. Перший крок – вивчити обов’язки, які описані в потоці подій для виявлення випадків використання. Класи-сутності – це зазвичай ті класи, які необхідні системі для виконання відповідних обов’язків. Використання іменників для опису обов’язків може стати хорошим початком. Початковий список потрібно профільтрувати, так як він буде містити слова, які не відносяться до предметної області, мовні вирази, надлишкові слова і іменники, що описують структуру класу. Класи-сутності зазвичай визначають на стадії проробки. Їх часто називають класами предметної області, тому що вони являються абстракціями предметів реального світу. Граничні класи Граничні класи (boundary class) забезпечують взаємодію між оточуючим середовищем і внутрішніми елементами системи. Такі класи забезпечують інтерфейс для користувача або іншої системи (тобто для актора). Вони складають зовнішньо залежну частину системи і використовуються для моделювання інтерфейсів системи. Для виявлення граничних класів вивчають пари актор/сценарій. Такі класи, які визначаються на етапі проробки, зазвичай, є класами верхнього рівня. Наприклад, ви можете змоделювати вікно, але не моделювати його діалогові елементи і кнопки. В такому випадку ви опишіть вимоги користувацького інтерфейсу, але не реалізуєте його. Граничні класи теж використовуються для забезпечення зв’язку з іншими системами. На етапі проектування ці класи вдосконалюються і виносяться на обговорення питань реалізації протоколів взаємодії. Керуючі класи Керуючі класи (control class) дозволяють моделювати послідовну поведінку одного або декількох випадків використання і координувати події, що реалізують закладену в них поведінку. Керуючі класи можна представити як класи, що «виконують» випадок використання і визначають його динаміку. Вони в більшості випадків залежать від програми. На ранній стадії проробки керуючі класи добавляються для кожної пари актор/випадок використання. Такі класи визначають потік подій в випадках використання. Питання використання керуючих класів дуже суб’єктивне. Багато авторів стверджують, що їх використання приводить до відділення даних від поведінки. Це справді може трапитися, якщо керуючі класи вибрані неакуратно. Якщо керуючий клас реалізує щось більше, ніж послідовну дію, то він робить занадто багато. Наприклад: в системі реєстрації курсів студент вибирає курс, і якщо курс доступний, студента записують на нього. Хто повинен знати, як прикріпити студента, – керуючий клас чи клас, що представляє курс занять? Правильна відповідь – клас, який представляє курс занять. Керуючий клас знає лише коли студент повинен бути прикріплений. «Поганий» керуючий клас знає не тільки те, коли, але й як прикріпити студента. Керуючий клас для кожної пари актор/випадок використання створюється на початковому етапі. При подальшому аналізі і проектуванні керуючі класи можуть виключатися, розділюватися і об’єднуватися. Етапи створення стереотипів для класів в програмі Rational Rose: Клікніть правою кнопкою миші по імені класу в списку оглядача. В контекстно-залежному меню, що появилося, виберіть команду Open Specification (відкрити параметри). Клікніть по закладці General (загальні). В випадному списку Stereotype (стереотип) виберіть потрібний стереотип. Щоб створити новий стереотип, введіть його ім’я в полі випадаючого списку Stereotype. Клікніть по кнопці OK, щоб закрити діалогове вікно налаштування параметрів класу. Документування класів Після того, як клас створений, інформацію про нього потрібно відобразити в документації. Документація призначена для опису призначення класу, а не його структури. Наприклад, клас студент може бути описаний наступним чином: Інформація необхідна для реєстрації студента і оплати навчання. Студент – людина, яка навчається в університеті. А ось приклад неправильного опису: Ім’я, адреса і телефон студента. Останній опис розкриває лише структуру класу, яку можна побачити, подивившись на список атрибутів, і не пояснює, для чого потрібний даний клас. Труднощі при виборі імені і опису класу можуть свідчити про те, що це не достатньо добра абстракція. В списку нижче перераховані можливі варіанти: Можна визначити ім’я і дати короткий, чіткий опис – хороший клас-кандидат; Можна визначити ім’я і вибрати опис, схожий на опис іншого класу – об’єднати класи; Можна визначити ім’я, але ціла книга буде потрібна для опису призначення класу – розділити клас; Неможливо визначити ім’я і дати опис – потрібно додатковий аналіз для виділення правильних абстракцій. Щоб описати класи в програмі Rational Rose: Виберіть клас в списку оглядача (браузера). Встановіть курсор у вікні опису і введіть опис класу. Пакети Якщо в системі є небагато класів, то керувати ними достатньо легко. Багато систем складаються з великої кількості класів, тому потрібний механізм, який би дав можливість розбити їх на групи і полегшити управління і повторне використання. Тут виявляється корисною концепція пакетів. Пакет (package) в логічному представленні моделі – набір класів і інших зв’язаних пакетів. Шляхом об’єднання класів в пакети ми можемо отримати представлення моделі на більш високому рівні. Вивчаючи вміст пакету, ми, навпаки, отримуємо більш детальне представлення. Кожний пакет містить інтерфейс, що реалізовується набором його загальнодоступних класів (public classes), тобто тих, до яких можуть звертатись класи з інших пакетів. Інші класи пакету – це класи реалізації (implementation classes), які не взаємодіють з класами з інших пакетів. В складній системі для полегшення сприйняття пакети можуть бути створенні на етапі проробки. В більш простій системі класи, що виділені на етапі аналізу, можуть бути згруповані в один пакет, що представляє саму систему. При подальшому аналізі і проектування пакети потрібні для групування класів, що використовуються в системній архітектурі. В мові UML пакети зображуються у вигляді папок. Щоб створити пакети в Rational Rose: Клікніть правою кнопкою миші по розділі Logical View (Логічне представлення) у вікні оглядача. В контекстно-залежному меню, що з’явилося, виберіть команду New→Package (Створити → Пакет). Введіть потрібне ім’я. Після створення пакету в нього можна помістити потрібні класи. Послідовність переміщення класів в пакет в програмі Rational Rose: В списку оглядача виділіть потрібний клас, клікнувши по ньому мишею. Втримуючи кнопку натиснутою, перетягніть клас в пакет. Повторіть ті ж дії для інших класів, які ви хочете перемістити. Діаграми класів По мірі того, як нові класи додаються в систему, їх текстове представлення стає незручним. Діаграма класів (class diagrams) допомагають графічно представити деякі або всі класи моделі. Головна діаграма класів в логічному представленні моделі зазвичай відображає пакети системи. Кожний пакет в свою чергу також має свою головну діаграму класів, яка зазвичай містить загальнодоступні класи пакету. Інші діаграми створюються при необхідності. Наведемо типові приклади використання діаграм класів: Перегляд всіх класів реалізації в пакеті; Перегляд структури і поведінки одного або декількох класів; Перегляд ієрархії наслідування класів. Програма Rational Rose автоматично створює головну діаграму класів в логічному представленні моделі. Щоб додати пакети до головної діаграми класів, зробіть наступне: Двічі клікніть по пункту списку Main diagram (Головна діаграма) у переглядачі, щоб відкрити діаграму. Оберіть потрібний пакет в списку, клікнувши по ньому мишею. Перетягніть пакет на діаграму. Аналогічним чином перетягніть на діаграму інші пакети. Етапи створення головної діаграми класів пакету в програмі Rational Rose: Двічі клікніть по зображенню пакету на діаграмі класів. Пакет відкриється і появиться головна діаграма класів. Виберіть потрібний клас в списку переглядача і перетягніть його на діаграму за допомогою миші. Для відображення стереотипу класу на діаграмі можна скористатися командою меню Format→Stereotype display (Формат → Показати стереотип). Повторіть попередній крок для інших класів, які ви хочете помістити на діаграму. Налаштування видимості класів за замовчуванням: Виберіть команду меню Tools→Options (Сервіс → Параметри). Клікніть по вкладці Diagram (Діаграма). Встановіть прапорець Show Visibility (Показати видимість) для відображення по замовчуванню всіх класів. Установка видимості для вибраного класу: Клікніть правою кнопкою миші по одному із класів на діаграмі. В контекстно-залежному меню, що появилося, виберіть команду Option → Show Visibility (Параметри → Показати видимість). Постановка задачі індивідуального завдання. Інформаційна система обліку поселень та бронювань у готелі. Клієнт готелю має мати змогу переглянути список вільних номерів і їх характеристики, теж повинен мати змогу забронювати місце на відповідне число, якщо номер вільний, та замовити список послуг. Для конкретного номеру на конкретне число повинна відображатися ціна найму. Реєстратор повинен мати змогу проглянути таблицю вільних місць на відповідне число. Також він повинен мати змогу забронювати відповідне місце, або здійснити поселення у відповідний номер. Система обслуговування (ресторан, та інші служби) повинні отримувати інформацію про те, які послуги замовлені, і в якому номері зупинився замовник. Практична частина. Дана інформаційна система складається із трьох пакетів, а саме: пакет даних для клієнта, пакет даних для реєстратора, пакет даних для системи обслуговування. Пакет даних для клієнта призначений для того, щоб клієнт міг бачити, які дії він може виконувати в цій інформаційній системі. Пакет даних для реєстратора створений для того, щоб реєстратор міг визначити, які обов’язки покладені на нього в інформаційній системі обліку поселень та бронювань у готелі. Пакет даних для системи обслуговування призначений для того, щоб ця система могла знати, які дії вона повинна виконувати в даній системі. Графічно це зображено на рис. 1.  Рис. 1. Інформаційна система, яка містить пакети Коротко опишемо вміст кожного пакету. Пакет «Пакет даних для клієнта» складається із чотирьох класів: перегляд списку послуг – це граничний клас, який надає клієнту можливість переглянути список послуг, які надає система обслуговування готелю; перегляд списку вільних номерів – це граничний клас, який надає клієнту можливість переглянути вільних номерів готелю, їх характеристики; заява на забронювання місць – це керуючий клас, який створюється клієнтом для подання реєстратору заяви для забронювання відповідного номера; замовлення послуг – це керуючий клас, який призначений для надання системі обслуговування готелю інформації про замовлені клієнтом послуги. Графічне зображення даного пакету представлено на рис. 2.  Рис. 2. Пакет даних для клієнта Пакет «Пакет даних для реєстратора» складається із чотирьох класів: визначення місця поселення клієнта – це граничний клас, який дозволяє реєстратору визначити номер, в який буде поселено клієнта; встановлення ціни найму – це граничний клас, який дозволяє реєстратору встановити для клієнта ціну найму за номер; поселення клієнтів – це керуючий клас, створений реєстратором, в якому зазначено номер, в якому поселено клієнта; надання системі обслуги списку місць – це керуючий клас, який призначений для надання системі обслуговування списку місць, в які поселено клієнтів. Графічне зображення даного пакету представлено на рис. 3.  Рис. 3. Пакет даних для реєстратора Пакет «Пакет даних для системи обслуговування» складається із трьох класів: отримання інформації про поселення клієнтів – це граничний клас, який дозволяє системі реєстрації отримати інформацію про місця поселення клієнтів; отримання інформації про послуги – це граничний клас, який дозволяє системі оплати отримати інформацію про замовлення клієнтів; надання клієнтам послуг – це керуючий клас, створений для того, щоб надавати клієнтам замовлені ними послуги. Графічне зображення даного пакету представлено на рис. 4.  Рис. 4. Пакет даних для системи обслуговування Висновки. Об’єкт – це концепція, абстракція або деталь з чітко визначеними межами і значенням для системи. Кожний об’єкт в системі має три характеристики: стан, поведінку і індивідуальність. Всі ці характеристики відображають існування об’єкту, умови, в яких він знаходиться, реакції на запити інших об’єктів, його унікальність. Клас – це опис групи об’єктів зі спільними властивостями, поведінкою, відношеннями з іншими об’єктами і семантикою. У мові UML класи відображаються у вигляді розділених прямокутників, у яких вказуються ім’я, структура і поведінка класу. Після створення класу необхідно його документувати. Стереотипи забезпечують можливість створення нових типів елементів моделювання і повинні бути засновані на елементах, які входять в модель мови UML. Шляхом об’єднання класів у пакети ми можемо отримати представлення моделі на більш високому рівні. Діаграми класів допомагають графічно зобразити деякі або всі класи системи.
Антиботан аватар за замовчуванням

31.03.2013 14:03-

Коментарі

Ви не можете залишити коментар. Для цього, будь ласка, увійдіть або зареєструйтесь.

Ділись своїми роботами та отримуй миттєві бонуси!

Маєш корисні навчальні матеріали, які припадають пилом на твоєму комп'ютері? Розрахункові, лабораторні, практичні чи контрольні роботи — завантажуй їх прямо зараз і одразу отримуй бали на свій рахунок! Заархівуй всі файли в один .zip (до 100 МБ) або завантажуй кожен файл окремо. Внесок у спільноту – це легкий спосіб допомогти іншим та отримати додаткові можливості на сайті. Твої старі роботи можуть приносити тобі нові нагороди!
Нічого не вибрано
0%

Оголошення від адміністратора

Антиботан аватар за замовчуванням

Подякувати Студентському архіву довільною сумою

Admin

26.02.2023 12:38

Дякуємо, що користуєтесь нашим архівом!