Автор работы: Пользователь скрыл имя, 18 Декабря 2012 в 12:43, лабораторная работа
Ознайомитися з основними поняттями, які використовуються при роботі з класами, а саме: клас, об’єкт, стан, поведінка, індивідуальність, пакет. Ознайомитися з принципами і прийомами побудови діаграми класів за допомогою програмного засобу Rational Rose. Навчитися застосовувати на практиці знання таких понять як клас, об’єкт, пакет, стереотип класу для побудови діаграм класів.
Міністерство освіти і науки, молоді та спорту України
Державний економіко-технологічний університет транспорту
Кафедра: «АКІТТ»
Лабораторна робота
На тему:
«Діаграма класів»
Виконала: ст. групи 4-КІКС
Сулима А.Ю.
Перевірив: викладач
Габчак М.К.
Київ 2012р.
МЕТА РОБОТИ
Ознайомитися з основними поняттями, які використовуються при роботі з класами, а саме: клас, об’єкт, стан, поведінка, індивідуальність, пакет. Ознайомитися з принципами і прийомами побудови діаграми класів за допомогою програмного засобу Rational Rose. Навчитися застосовувати на практиці знання таких понять як клас, об’єкт, пакет, стереотип класу для побудови діаграм класів.
Поняття об’єкту
Об’єкт (object) – деяка сутність реального світу або концептуальна сутність. Об’єкт може бути чимось конкретним, наприклад грузовик або мій комп’ютер, або концептуальним, як ,наприклад, хімічний процес, банківська операція, торгове замовлення, діловий договір і т.д.
Об’єктом називається концепція, абстракція або річ з чітко визначеними границями і значенням для системи. Кожний об’єкт в системі має три характеристики: стан, поведінка, індивідуальність.
Стан, поведінка, індивідуальність
Станом (state) об’єкту називається одна з умов, в яких він може знаходитись. Стан системи зазвичай змінюється з часом і визначається набором властивостей, які називаються атрибутами (attribute), значень властивостей і відношень між об’єктами. Наприклад, об’єкт навчальний курс (CourseOffering) в системі реєстрації навчальних курсів може знаходитися в одному з двох станів: відкритий для запису або закритий для запису. Якщо кількість студентів, що зареєструвалися на курс, менша ніж дев’ять, то запис на курс продовжується. Після реєстрації дев’ятого студента вона припиняється.
Поведінка (behavior) визначає те, як об’єкт реагує на запити інших об’єктів і що може робити сам об’єкт. Поведінка реалізується за допомогою набору операцій (operation) для об’єкту. В системі реєстрації курсів об’єкт навчальний курс може мати операції добавити студента і видалити студента.
Індивідуальність (identity) означає, що кожний об’єкт унікальний, навіть якщо його стан є ідентичний стану іншого об’єкта. Наприклад Алгебра 101, секція 1 і Алгебра 101, секція 2 – два об’єкти в системі реєстрації курсів. Хоча кожен із них є навчальним курсом, кожен із них є унікальним.
В мові UML об’єкт зображується у вигляді прямокутника, а його ім’я пишеться з підчеркуванням (рис.1)
Рис.1. Нотація мови UML для об’єкту
Поняття класу
Клас (class) – це опис групи об’єктів з спільними властивостями (атрибутами), поведінкою (операціями), відношеннями з іншими об’єктами і семантикою. Таким чином, клас представляє собою шаблон для створення об’єкту. Кожний об’єкт є екземпляром конкретного класу і не може бути екземпляром декількох класів. Наприклад, клас навчальний курс (CourseOffering) може визначатися наступними характеристиками:
Алгебра 101, секція 1 і Алгебра 101, секція 2 – це об’єкти, які належать до класу навчальний курс. Кожний об’єкт має значення атрибутів і доступ до операцій, які визначені класом навчальний курс.
«Хороший» клас являє собою одну і тільки одну абстракцію, тобто повинен відображати одну основну сутність. Наприклад, клас, що зберігає інформацію про студентів і дані про курси, які студент відвідує протягом декількох років, не є «хорошим» класом тому, що не представляє тільки одну сутність. Такий клас треба розділити на два пов’язаних класи: студент і історія студента.
Назви класів обираються у відповідності до понять предметної області. Ім’я повинно бути іменником в однині, який найбільш точно характеризує предмет.
В мові UML класи зображають у вигляді розділених прямокутників. В верхній секції вказується ім’я класу, середня секція містить його структуру – атрибути, а нижня описує його поведінку – операції. Клас зображений на рис.2
Рис.2. Нотація мови UML для класу
Порядок створення класів в програмі Rational Rose:
Рис.3. Вікно оглядача після створення класу
Стереотипи і класи
Про стереотипи вже згадувалось при розгляді діаграми випадків використання. Класи теж можуть мати стереотипи. Як і раніше, стереотип використовується для створення нового типу елементу моделювання, в даному випадку для створення нових типів класів. Деякі основні стереотипи класу – сутність, граничний елемент, елемент управління, сервісний елемент і виключення.
Стереотип класу вказується під його ім’ям і береться в подвійні лапки. В програмі Rational Rose є зображення для стереотипів Rational Unified Process – управляючого елементу, сутності і граничного елементу. Ці стереотипи, а також приклад класу із стереотипом виключення показані на рис.4.
Рис.4. Класи із стереотипами
Виявлення класів
Рецептів для знаходження класів не існує. Насправді це дійсно важко. З причини того, що процес аналізу і проектування ітеративний, то список класів з часом змінюється. Початковий набір класів скоріш за все буде відрізнятися від кінцевого. Тому для опису початкового набору класів, виявлених в системі, часто використовують термін «клас-кандидат».
Класи-сутності
Клас-сутність (entity class) використовується для моделювання даних і поведінки з довгим життєвим циклом. Цей тип класів може представляти сутності реального світу або внутрішні елементи системи. Такі класи зазвичай не залежать від оточення, тобто вони нечутливі до взаємодії зовнішнього середовища з системою. Відповідно, вони не залежать від програми і можуть застосовуватися в різних програмах.
Перший
крок – вивчити обов’язки, які
описані в потоці подій для
виявлення випадків використання. Класи-сутності
– це зазвичай ті класи, які необхідні
системі для виконання
Класи-сутності
зазвичай визначають на стадії проробки.
Їх часто називають класами
Граничні класи
Граничні класи (boundary class) забезпечують взаємодію між оточуючим середовищем і внутрішніми елементами системи. Такі класи забезпечують інтерфейс для користувача або іншої системи (тобто для актора). Вони складають зовнішньо залежну частину системи і використовуються для моделювання інтерфейсів системи.
Для виявлення граничних класів вивчають пари актор/сценарій. Такі класи, які визначаються на етапі проробки, зазвичай, є класами верхнього рівня. Наприклад, ви можете змоделювати вікно, але не моделювати його діалогові елементи і кнопки. В такому випадку ви опишите вимоги користувацького інтерфейсу, але не реалізуєте його.
Граничні класи теж використовуються для забезпечення зв’язку з іншими системами. На етапі проектування ці класи вдосконалюються і виносяться на обговорення питань реалізації протоколів взаємодії.
Керуючі класи
Керуючі класи (control class) дозволяють моделювати послідовну поведінку одного або декількох випадків використання і координувати події, що реалізують закладену в них поведінку. Керуючі класи можна представити як класи, що «виконують» випадок використання і визначають його динаміку. Вони в більшості випадків залежать від програми.
На ранній стадії проробки керуючі класи добавляються для кожної пари актор/випадок використання. Такі класи визначають потік подій в випадках використання.
Питання використання керуючих класів дуже суб’єктивне. Багато авторів стверджують, що їх використання приводить до відділення даних від поведінки. Це справді може трапитися, якщо керуючі класи вибрані неакуратно. Якщо керуючий клас реалізує щось більше, ніж послідовну дію, то він робить занадто багато. Наприклад: в системі реєстрації курсів студент вибирає курс, і якщо курс доступний, студента записують на нього.
Хто повинен знати, як прикріпити студента, – керуючий клас чи клас, що представляє курс занять? Правильна відповідь – клас, який представляє курс занять. Керуючий клас знає лише коли студент повинен бути прикріплений. «Поганий» керуючий клас знає не тільки те, коли, але й як прикріпити студента.
Керуючий клас для кожної пари актор/випадок використання створюється на початковому етапі. При подальшому аналізі і проектуванні керуючі класи можуть виключатися, розділюватися і об’єднуватися.
Етапи створення стереотипів для класів в програмі Rational Rose:
Рис.5. Встановлення стереотипу класу.
Документування класів
Після того, як клас створений, інформацію про нього потрібно відобразити в документації. Документація призначена для опису призначення класу, а не його структури. Наприклад, клас студент може бути описаний наступним чином:
Інформація необхідна для реєстрації студента і оплати навчання. Студент – людина, яка навчається в університеті.
А ось приклад неправильного опису:
Ім’я, адреса і телефон студента.
Останній опис розкриває лише структуру класу, яку можна побачити, подивившись на список атрибутів, і не пояснює, для чого потрібний даний клас.
Труднощі при виборі імені і опису класу можуть свідчити про те, що це не достатньо добра абстракція. В списку нижче перераховані можливі варіанти:
Щоб описати класи в програмі Rational Rose:
Пакети
Якщо в системі є небагато класів, то керувати ними достатньо легко. Багато систем складаються з великої кількості класів, тому потрібний механізм, який би дав можливість розбити їх на групи і полегшити управління і повторне використання. Тут виявляється корисною концепція пакетів.
Пакет (package) в логічному представленні моделі – набір класів і інших зв’язаних пакетів. Шляхом об’єднання класів в пакети ми можемо отримати представлення моделі на більш високому рівні. Вивчаючи вміст пакету, ми, навпаки, отримуємо більш детальне представлення.
Кожний пакет містить інтерфейс, що реалізовується набором його загальнодоступних класів (public classes), тобто тих, до яких можуть звертатись класи з інших пакетів. Інші класи пакету – це класи реалізації (implementation classes), які не взаємодіють з класами з інших пакетів.
В складній системі для полегшення сприйняття пакети можуть бути створенні на етапі проробки. В більш простій системі класи, що виділені на етапі аналізу, можуть бути згруповані в один пакет, що представляє саму систему. При подальшому аналізі і проектування пакети потрібні для групування класів, що використовуються в системній архітектурі.
В мові UML пакети зображуються у вигляді папок. Щоб створити пакети в Rational Rose: