Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Комп'ютерні науки
Кафедра:
Не вказано
Інформація про роботу
Рік:
2008
Тип роботи:
Інші
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
Кафедра ПЗ
Класи та діаграми класів в Rational Rose
Методичні матеріали
до лабораторної роботи № 4 з курсу:
“Основи проектування інформаційних систем”
для студентів базового напрямку
6.0804 “Комп’ютерні науки”
ЗАТВЕРДЖЕНО
на засіданні кафедри
“Програмне забезпечення”
Протокол №
від
ЛЬВІВ 2008
Класи та діаграми класів в Rational Rose. Методичні матеріали до лабораторної роботи № 4 з курсу: “ Основи проектування інформаційних систем ” для студентів базового напрямку 6.0804 “Комп’ю тер ні науки”.
Укладачі:
Макар В.М., доцент, к.т.н.
Муха Т.О., асистент.
Відповідальний за випуск:
Рецензенти:
1. МЕТА РОБОТИ
Ознайомитися з основними поняттями, які використовуються при роботі з класами, а саме: клас, об’єкт, стан, поведінка, індивідуальність, пакет. Ознайомитися з принципами і прийомами побудови діаграми класів за допомогою програмного засобу Rational Rose. Навчитися застосовувати на практиці знання таких понять як клас, об’єкт, пакет, стереотип класу для побудови діаграм класів.
2.ОСНОВНІ ТЕОРЕТИЧНІ ВІДОМОСТІ
2.1 Постановка модельної задачі
Основним прикладом, що буде розглядатися є реєстрація курсів в університеті ESU (Eastern State University). Після того, як викладачі ESU вирішать, які курси вони будуть вести протягом семестру, служба реєстрації курсів введе інформацію в комп’ютерну систему. Потім для викладачів видрукують сумарний звіт по курсах, які вони читатимуть, а для студентів – каталог курсів.
На цьому етапі студенти заповнюють спеціальну реєстраційну форму, де вказують вибрані курси і віддають її в службу реєстрації. Зазвичай студент підписується на чотири курси, після чого інформація заноситься в комп’ютер. Після цього запускається нічна пакетна програма, яка розподіляє студентів по курсах. При виникненні конфліктної ситуації служба реєстрації уточнює дані студента. Після вдалого розподілення студенту висилається розклад для провірки. Зазвичай, процес реєстрації на курси займає близько тижня, проте в ряді випадків може бути потрібно до двох тижнів, щоб залагодити всі питання. Після цього викладачі отримують список студентів для кожного курсу, який вони будуть читати.
Постановка задачі реєстрації курсів:
На початку кожного семестру студенти можуть запросити каталог курсів, в який включений список предметів, навчання по яких пропонується в даному семестрі. Інформація про курси повинна містити прізвище викладача, назву факультету і короткий опис, який допоможе студентам зробити вибір.
Нова система дозволить студенту здійснити вибір чотирьох курсів, із тих що пропонуються в наступаючому семестрі. Крім того студенту потрібно вказати ще два варіанта на випадок якщо курс буде відмінений або переповнений. На курс не повинно бути записано більше десяти і менше трьох студентів. Курс, на який запишеться менше трьох студентів буде відмінений. Після закінчення реєстрації система реєстрації направляє інформацію в систему оплати для виставлення рахунків студентам.
Викладачі повинні мати можливість он-лайнового доступу до системи для вказання курсів, які вони будуть читати, і для перегляду списку студентів, що записалися. В кожному семестрі виділяється визначений час, протягом якого студенти можуть міняти свій розклад і отримувати доступ до системи для додавання і видалення вибраних курсів.
2.2. Поняття об’єкту
Об’єкт (object) – деяка сутність реального світу або концептуальна сутність. Об’єкт може бути чимось конкретним, наприклад грузовик або мій комп’ютер, або концептуальним, як, наприклад, хімічний процес, банківська операція, торгове замовлення, діловий договір і т.д. Об’єктом називається концепція, абстракція або річ з чітко визначеними границями і значенням для системи. Кожний об’єкт в системі має три характеристики: стан, поведінка, індивідуальність.
Станом (state) об’єкту називається одна з умов, в яких він може зна хо ди тись. Стан системи зазвичай змінюється з часом і визначається набором влас тивостей, які називаються атрибутами (attribute), значень властивостей і відношень між об’єктами. Наприклад, об’єкт навчальний курс (CourseOffering) в системі реєстрації навчальних курсів може знаходитися в одному з двох станів: відкритий для запису або закритий для запису. Якщо кількість студентів, що зареєструвалися на курс, менша ніж дев’ять, то запис на курс продовжується. Після реєстрації дев’ятого студента вона припиняється.
Поведінка (behavior) визначає те, як об’єкт реагує на запити інших об’єк тів і що може робити сам об’єкт. Поведінка реалізується за допомогою набо ру операцій (operation) для об’єкту. В системі реєстрації курсів об’єкт навчальний курс може мати операції добавити студента і видалити студента.
Індивідуальність (identity) означає, що кожний об’єкт унікальний, навіть якщо його стан є ідентичний стану іншого об’єкта. Наприклад Алгебра 101, секція 1 і Алгебра 101, секція 2 – два об’єкти в системі реєстрації курсів. Хоча кожен із них є навчальним курсом, кожен із них є унікальним.
В мові UML об’єкт зображується у вигляді прямокутника, а його ім’я пишеться з підчеркуванням (рис.1)
Рис.1. Нотація мови UML для об’єкту
2.3. Поняття класу
Клас (class) – це опис групи об’єктів з спільними властивостями (атри бу та ми), поведінкою (операціями), відношеннями з іншими об’єктами і семан ти кою. Таким чином, клас представляє собою шаблон для створення об’єкту. Кожний об’єкт є екземпляром конкретного класу і не може бути екземпляром декількох класів. Наприклад, клас навчальний курс (CourseOffering) може визначатися наступними характеристиками:
Атрибути – місце занять, час занять;
Операції – отримати місце занять, отримати час занять, додати студента на курс.
Алгебра 101, секція 1 і Алгебра 101, секція 2 – це об’єкти, які належать до класу навчальний курс. Кожний об’єкт має значення атрибутів і доступ до операцій, які визначені класом навчальний курс.
«Хороший» клас являє собою одну і тільки одну абстракцію, тобто повинен відображати одну основну сутність. Наприклад, клас, що зберігає інформацію про студентів і дані про курси, які студент відвідує протягом декількох років, не є «хорошим» класом тому, що не представляє тільки одну сутність. Такий клас треба розділити на два пов’язаних класи: студент і історія студента.
Назви класів обираються у відповідності до понять предметної області. Ім’я повинно бути іменником в однині, який найбільш точно характеризує предмет. В мові UML класи зображають у вигляді розділених на секції прямокутників. В верхній секції вказується ім’я класу, середня секція містить його структуру – атрибути, а нижня описує його поведінку – операції (рис.2).
Рис.2. Нотація мови UML для класу
Порядок створення класів в програмі Rational Rose:
Клікніть правою кнопкою миші по розділі Logical View (Логічне представлення) у вікні оглядача.
В контекстно-залежному меню, що з’явилося, оберіть команду New→Class (Створити→Клас). У список оглядача буде добавлено новий клас з ім’ям New Class.
Введіть потрібне ім’я класу.
Рис.3. Вікно оглядача після створення класу
2.4. Стереотипи і класи
Про стереотипи вже згадувалось при розгляді діаграм випадків вико рис тання. Класи теж можуть мати стереотипи. Як і раніше, стереотип вико рис товується для створення нового типу елементу моделювання, в даному ви пад ку для створення нових типів класів. Основні стереотипи класу: сут ніст ь, граничний елемент, елемент управління, сервісний елемент і виключення.
Стереотип класу вказується під його ім’ям і береться в подвійні лапки. В програмі Rational Rose є зображення для стереотипів Rational Unified Process – управляючого елементу, сутності і граничного елементу. Ці стереотипи, а також приклад класу із стереотипом виключення показані на рис.4.
Рис.4. Класи із стереотипами
2.5. Виявлення класів
Ідентифікація класів заданої предметної області – одна з найважчих задач процесу проектування. У зв’язку з тим, що процес аналізу і проек ту ван ня ітеративний, то список класів з часом змінюється. Початковий набір кла сів скоріш за все буде відрізнятися від кінцевого. Тому для опису почат ко вого набору класів, виявлених в системі, часто використовують термін «клас-кандидат». Методологія Rational Unified Process містить засоби, що допомагають виявити класи типу сутність, граничний та керуючий елементи.
Клас-сутність (entity class) використовується для моделювання даних і по ведінки з довгим життєвим циклом. Цей тип класів може представляти сут ності реального світу або внутрішні елементи системи. Такі класи зазвичай не залежать від оточення, тобто вони нечутливі до взаємодії зовнішнього се ре довища з системою. Відповідно, вони не залежать від програми і можуть застосовуватися в різних програмах.
Перший крок – вивчити обов’язки, які описані в потоці подій для виявлення випадків використання. Класи-сутності – це зазвичай ті класи, які необхідні системі для виконання відповідних обов’язків. Використання іменників для опису обов’язків може стати хорошим початком. Початковий список потрібно профільтрувати, так як він буде містити слова, які не відносяться до предметної області, мовні вирази, надлишкові слова і іменники, що описують структуру класу. Класи-сутності зазвичай визначають на стадії проробки. Їх часто називають класами предметної області, тому що вони являються абстракціями предметів реального світу.
Граничні класи (boundary class) забезпечують взаємодію між оточуючим середовищем і внутрішніми елементами системи. Такі класи забезпечують інтерфейс для користувача або іншої системи (тобто для актора). Вони складають зовнішньо залежну частину системи і використовуються для моделювання інтерфейсів системи.
Для виявлення граничних класів вивчають пари актор/сценарій. Такі класи, які визначаються на етапі проробки, зазвичай, є класами верхнього рівня. Наприклад, ви можете змоделювати вікно, але не моделювати його діалогові елементи і кнопки. В такому випадку ви опишите вимоги користувацького інтерфейсу, але не реалізуєте його.
Граничні класи теж використовуються для забезпечення зв’язку з іншими системами. На етапі проектування ці класи вдосконалюються і виносяться на обговорення питань реалізації протоколів взаємодії.
Керуючі класи (control class) дозволяють моделювати послідовну поведінку одного або декількох випадків використання і координувати події, що реалізують закладену в них поведінку. Керуючі класи можна представити як класи, що «виконують» випадок використання і визначають його динаміку. Вони в більшості випадків залежать від програми.
На ранній стадії проробки керуючі класи добавляються для кожної пари актор/випадок використання. Такі класи визначають потік подій в випадках використання.
Питання використання керуючих класів дуже суб’єктивне. Багато авторів стверджують, що їх використання приводить до відділення даних від поведінки. Це справді може трапитися, якщо керуючі класи вибрані неакуратно. Якщо керуючий клас реалізує щось більше, ніж послідовну дію, то він робить занадто багато. Наприклад: в системі реєстрації курсів студент вибирає курс, і якщо курс доступний, студента записують на нього.
Хто повинен знати, як прикріпити студента, – керуючий клас чи клас, що представляє курс занять? Правильна відповідь – клас, який представляє курс занять. Керуючий клас знає лише коли студент повинен бути прикріплений. «Поганий» керуючий клас знає не тільки те, коли, але й як прикріпити студента.
Керуючий клас для кожної пари актор/випадок використання створюється на початковому етапі. При подальшому аналізі і проектуванні керуючі класи можуть виключатися, розділюватися і об’єднуватися.
Етапи створення стереотипів для класів в програмі Rational Rose:
Клікніть правою кнопкою миші по імені класу в списку оглядача.
В контекстно-залежному меню, що появилося, виберіть команду Open Specification (відкрити параметри).
Клікніть по закладці General (загальні).
В випадному списку Stereotype (стереотип) виберіть потрібний стереотип. Щоб створити новий стереотип, введіть його ім’я в полі випадаючого списку Stereotype.
Клікніть по кнопці OK, щоб закрити діалогове вікно налаштування параметрів класу.
2.6. Документування класів
Після того, як клас створений, інформацію про нього потрібно відобразити в документації. Документація призначена для опису призначення класу, а не його структури. Наприклад, клас студент може бути описаний наступним чином:
Інформація необхідна для реєстрації студента і оплати навчання. Студент – людина, яка навчається в університеті.
А ось приклад неправильного опису:
Ім’я, адреса і телефон студента.
Останній опис розкриває лише структуру класу, яку можна побачити, подивившись на список атрибутів, і не пояснює, для чого потрібний даний клас. Труднощі при виборі імені і опису класу можуть свідчити про те, що це не достатньо добра абстракція. В списку нижче перераховані можливі варіанти:
Можна визначити ім’я і дати короткий, чіткий опис – хороший клас-кандидат;
Можна визначити ім’я і вибрати опис, схожий на опис іншого класу – об’єднати класи;
Можна визначити ім’я, але ціла книга буде потрібна для опису призначення класу – розділити клас;
Неможливо визначити ім’я і дати опис – потрібно додатковий аналіз для виділення правильних абстракцій.
Щоб описати класи в програмі Rational Rose:
Виберіть клас в списку оглядача (браузера).
Встановіть курсор у вікні опису і введіть опис класу.
2.7. Пакети
Якщо в системі є небагато класів, то керувати ними достатньо легко. Багато систем складаються з великої кількості класів, тому потрібний ме ха нізм, який би дав можливість розбити їх на групи і полегшити управління і повторне використання. Тут виявляється корисною концепція пакетів.
Пакет (package) в логічному представленні моделі – набір класів і інших зв’язаних пакетів. Шляхом об’єднання класів в пакети ми можемо отримати представлення моделі на більш високому рівні. Вивчаючи вміст пакету, ми, навпаки, отримуємо більш детальне представлення.
Кожний пакет містить інтерфейс, що реалізовується набором його загаль нодоступних класів (public classes), тобто тих, до яких можуть звер та тись класи з інших пакетів. Інші класи пакету – це класи реалізації (implementation classes), які не взаємодіють з класами з інших пакетів.
В складній системі для полегшення сприйняття пакети можуть бути створенні на етапі проробки. В більш простій системі класи, що виділені на етапі аналізу, можуть бути згруповані в один пакет, що представляє саму систему. При подальшому аналізі і проектування пакети потрібні для групування класів, що використовуються в системній архітектурі.
В мові UML пакети зображуються у вигляді папок. Щоб створити пакети в Rational Rose:
Клікніть правою кнопкою миші по розділі Logical View (Логічне представлення) у вікні оглядача.
В контекстно-залежному меню, що з’явилося, виберіть команду New→Package (Створити → Пакет).
Введіть потрібне ім’я.
Після створення пакету в нього можна помістити потрібні класи.
Послідовність переміщення класів в пакет в програмі Rational Rose:
В списку оглядача виділіть потрібний клас, клікнувши по ньому мишею.
Втримуючи кнопку натиснутою, перетягніть клас в пакет.
Повторіть ті ж дії для інших класів, які ви хочете перемістити.
Рис.5. Вигляд Логічного Представлення до і після переміщення класу в пакет
2.8. Відношення між класами
Рідко коли класи в системі бувають автономними. Як правило, вони взаємодіють один з одним. Ці взаємодії відображаються за допомогою відношень різного типу. Двома основними типами відношень, які можна ви ді лити на етапі аналізу є асоціація та агрегація.
Асоціація (association) — це семантичний зв'язок між класами. Асоціація відображає структурні зв'язки між об'єктами різних класів. Наявність асоціації між класами означає, що об’єкти цих класів взаємозвязані. Даний вид зв’язку показує, що один клас включається в інший як атрибут за по си лан ням. Відношення асоціації зображають на діаграмі класів у вигляді зви чай ної лінії. Послідовність створення відношення асоціації в Rational Rose:
Клікніть кнопку Association на панелі інструментів.
На діаграмі класів клікніть на потрібному класі.
Перетягніть лінію асоціативного відношення, яка з’явилася, на другий клас, який буде брати участь у цьому зв’язку.
Агрегація (aggregation) – це спеціальний вид асоціації між цілим та його частинами. Віношення агрегації – це відношення типу “part of”. Агрегація означає, що один клас не тільки використовує інший, а й містить інший клас як складову частину. В мові UML вона зображається лінією між класами з ромбом на стороні цілого. Для того, щоб визначити чи асоціативний зв’язок є агрегативним рекомендується дати відповіді на такі тестові питання:
1) чи для опису відношення можна застосувати фразу типу “є частиною ...”?
2) чи можна при описі відношення сказати, що один клас підпорядковується іншому?
3) чи виконаня деяких операцій над цілим означає автоматичне їх виконання над його частинами?
Щоб створити відношення агрегації в Rational Rose виконайте такі дії
Клікніть кнопку Aggregation на панелі інструментів.
На діаграмі класів клікніть на класі, який буде виступати в ролі цілого.
Перетягніть лінію відношення агрегації, яка з’явилася, на клас, який буде брати участь у цьому зв’язку в ролі складової частини.
Відношення можна уточнити за допомогою назв або ролевих імен, які, як правило задаються дієсловом, що описує призначення цього відношення. Наприклад, між класом Викладач і класом Навчальний курс може існувати асоціація, яку можна назвати «читає». Називати відношення не обов'язково. Звичайно це роблять, якщо причина створення зв'язку не очевидна. Ім'я показують біля лінії відповідного зв'язку.
Для уточнення ролі, яку грає кожен клас в зв'язках асоціації або агрегації, застосовують ролеві імена. Повертаючись до прикладу з класами Викладач і Навчальний курс, можна сказати, що клас Викладач грає роль вчителя для Навчального курсу. Ролеві імена — це, зазвичай, імен ники або засновані на них фрази, їх показують на діаграмі поряд з класом, який грає відповідну роль. Як правило, користуються або ролевим ім'ям, або назвою відношення, але не обома відразу. Як і назви, ролеві імена не обов'язкові, їх дають, тільки якщо сенс зв'язку не очевидний. Задати ролеві імена можна командою Role Name контекстно-залежного меню відношення.
Потужність (multiplicity) показує, як багато об'єктів бере участь у від но шенні. По туж ність - це число об'єктів одного класу, зв’язаних з одним об'єктом іншого класу. Для кожного відношення можна задати два показники потужності – по одному на кожному кінці зв'язку. У мові UML прийняті наступні нотації для позначення потужності.
Потужність
Значення
*
Багато
0
Нуль
1
Один
0..*
Нуль або більше
1..*
Один або більше
0..1
Нуль або один
1..1
Рівно один
Наприклад, розглянемо класи Навчальний курс і Студент. Між ними встановлений зв'язок, що означає відві ду вання курсів студентами. Якщо один студент може відвідувати від нуля до чотирьох курсів, а на одному курсі можуть займатися від 10 до 20 студентів, то на діаграмі класів це можна зобразити таким чином:
Для того, щоб задати потужність зв’язку в Rational Rose виконайте дії:
Двічі клікніть по лінії зв’язку на діаграмі – відкриється діалогове вікно Specification.
Виберіть закладку Detail для потрібної ролі.
Вкажіть потрібне значення потужності зв’язку в списку Multiplicity і закрийте вікно за допомогою кнопки OK.
Частковим випадком асоціації є асоціація-клас (Association class), яка во ло діє як влас ти вос тями класу, так і властивостями асоціації. Асоціація-клас - це місце, де зберігаються атри бу ти, що відносяться і до асоціації, і до опе ра ції. Екземплярами асоціації-класу є зв'язки, у яких є не тільки посилання на об'єкти, але і значення атрибутів. Допустимо, що є два класи, Студент і Навчальний курс, і виникла необхідність додати атрибут Оцінка. У такому разі виникає питання, в який клас треба його додати. Якщо помістити його усередині класу Студент, то доведеться вводити його для кожного відвідуваного студентом курсу, що дуже сильно збільшить розмір цього класу. Якщо ж помістити його усередині класу Навчальний курс, то доведеться задавати його для кожного студента, який відвідує цей курс. Щоб ви рі ши ти цю проблему, можна створити асоціацію-клас. У цей клас слід помістити атрибут Grade, що відноситься до зв'язку між курсом і студентом. Нотація UML для асоціації-класу зображається так:
Між пакетами також можуть існувати відношення. Такий тип зв’язку є відношенням залежності з зображенням у вигляді пунктирної стрілки у напрямку до залежного пакету. Якщо пакет А залежить від пакету В, то це означає, що один чи декілька класів в пакеті А ініціюють зв’язок з одним чи декількома класами пакету В. Пакет А тоді називається клієнтом, а пакет В – постачальником.
2.9. Об’єкти і класи в системі реєстрації курсів
Розглянемо сценарій додавання навчального курсу (Add a Course Offering to Teach), який являється потоком подій для випадку використання вибір курсів для викладання (Select Courses to Teach). Цей сценарій дозволяє викладачу вибрати навчальний курс для конкретного семестру.
Випадок використання, який розглядається, взаємодіє тільки з актором викладач. Дія, яку виконує даний сценарій – це тільки одна з можливостей, яка забезпечується випадком використання (він також визначає, що викладач може змінювати, видаляти, переглядати і друкувати курси). Це означає, що в системі повинен бути механізм, який дозволяє користувачу вибирати дію, яку він бажає здійснити. Для забезпечення потреб викладачів створюється спеціальний клас – параметри курсу викладача (ProfessorCourseOption). Додатково ми можемо вказати клас, який слугує для додавання нових курсів, доступних викладачеві – додавання навчального курсу (AddCourseOffering).
Даний сценарій складається з предметів, навчальних курсів і приз начення викладачів. Ми можемо виділити три класи-сутності: предмет (Course), навчальний курс (CourseOffering) і викладач (Professor).
Додамо один керуючий клас з ціллю обробки потоку подій випадку використання – менеджер курсів викладача (ProfessorCourseManager).
Вибрані класи (з встановленими стереотипами сутність, керуючий елемент і граничний елемент) можуть бути додані до моделі (рис.6). Так як актор викладач вже існує, то при створені класу викладач програма Rational Rose попередить, що одне і те ж ім’я використовується в різних розділах.
Наступний крок – об’єднати класи в пакети. На даному етапі виділимо шість класів: предмет, навчальний курс, викладач, параметри курсу викладача, додавання навчального курсу і менеджер курсів викладача. Їх можна розділити на три логічні групи: об’єкти, специфічні для університету; об’єкти, що містять інформацію про людей; інтерфейси для акторів. Таким чином, ми можемо створити наступні пакети: інтерфейси (Interfaces), об’єкти університету (UniversityArtifacts) і дані про людей (PeopleInfo). Після цього класи поміщаються у відповідні пакети.
a) b)
Рис.6. Класи (a) та пакети (b) модельної задачі
2.10. Діаграми класів
По мірі того, як нові класи додаються в систему, їх текстове представлення стає незручним. Діаграма класів (class diagrams) допомагають графічно представити деякі або всі класи моделі.
Головна діаграма класів в логічному представленні моделі зазвичай відображає пакети системи. Кожний пакет в свою чергу також має свою головну діаграму класів, яка зазвичай містить загальнодоступні класи пакету. Інші діаграми створюються при необхідності. Приведем типові приклади використання діаграм класів:
перегляд всіх класів реалізації в пакеті;
перегляд структури і поведінки одного або декількох класів;
перегляд відношень між класами;
перегляд ієрархії наслідування класів.
Програма Rational Rose автоматично створює головну діаграму класів в логічному представленні моделі.
Щоб додати пакети до головної діаграми класів, зробіть наступне:
Двічі клікніть по пункту списку Main diagram (Головна діаграма) у переглядачі, щоб відкрити діаграму.
Оберіть потрібний пакет в списку, клікнувши по ньому мишею.
Перетягніть пакет на діаграму.
Аналогічним чином перетягніть на діаграму інші пакети.
Головна діаграма класів для системи реєстрації показана на рис. 7.
Рис.7. Головна діаграма класів для системи реєстрації
Етапи створення головної діаграми класів пакету в Rational Rose:
Двічі клікніть по зображенню пакету на діаграмі класів.
Пакет відкриється і появиться головна діаграма класів.
Виберіть потрібний клас в списку переглядача і перетягніть його на діаграму за допомогою миші. Для відображення стереотипу класу на діаграмі можна скористатися командою меню Format→Stereotype display (Формат → Показати стереотип).
Повторіть попередній крок для інших класів, які ви хочете помістити на діаграму.
Головна діаграма класів для пакету Об’єкти університету зображена нижче. Зауважте, що клас навчальний курс на ній відсутній. Це клас реалізації в пакеті, тому ми вирішили не показувати його на головній діаграмі. По мірі додавання пакетів і класів можуть бути створені додаткові діаграми.
Рис.8. Діаграма класів для пакету Об’єкти університету
Налаштування видимості класів за замовчуванням:
Виберіть команду меню Tools→Options (Сервіс → Параметри).
Клікніть по вкладці Diagram (Діаграма).
Встановіть прапорець Show Visibility (Показати видимість) для відображення по замовчуванню всіх класів.
Установка видимості для вибраного класу:
Клікніть правою кнопкою миші по одному із класів на діаграмі.
В контекстно-залежному меню, що появилося, виберіть команду Option → Show Visibility (Параметри → Показати видимість).
Взаємодіючі класи та типи відношень для сценарію додавання навчального курсу випадку використання вибір курсів для викладання перераховані в таблиці 1.
Таблиця 1.Відношення між класами
Клас-ініціатор
Клас-споживач
Тип
Параметри курсу викладача
Додавання навчального курсу
Агрегація
Додавання навчального курсу
Менеджер курсів викладача
Асоціація
Менеджер курсів викладача
Предмет
Асоціація
Предмет
Навчальний курс
Агрегація
Діаграма класів з даними відношеннями зображена на рис. 10.
Рис.9. Діаграма класів, яка відображає видимість пакетів
Рис.10. Діаграма класів, яка відображає відношення між класам
3.КОНТРОЛЬНІ ЗАПИТАННЯ
Які особливості поняття «об’єкт»?
Що являє собою поняття «клас»?
Які є основні стереотипи класів і для чого вони використовуються?
В чому полягає сут відношення асоціації між класами?
Що таке відношення агрегації? Як розрізнити асоціацію та агрегацію?
Що таке потужність зв’язку? Які значення може приймати потужність?
Для чого використовуються діаграми класів? Які типи діаграм класів ви знаєте?
Для чого використовується поняття пакету?
4.ЛАБОРАТОРНЕ ЗАВДАННЯ
Ознайомитися з основними поняттями та елементами для побудови діаграми класів.
Провести аналіз завдання (індивідуальні завдання наведені в Додатку) визначити класи-сутності, керуючі класи та граничні класи.
Побудувати діаграми класів.
Оформити і здати звіт про виконання лабораторної роботи.
5.ЗМІСТ ЗВІТУ
Мета роботи.
Короткі теоретичні відомості.
Постановка задачі індивідуального завдання.
Оформлений належним чином (з коментарями та поясненнями) список класів, з зазначенням їхніх стереотипів, список пакетів з коротким описом ходу міркувань, з яких ви вибрали саме такий набір класів і пакетів, а також відповідні діаграми класів.
Аналіз результатів та висновки.
6.СПИСОК РЕКОМЕНДОВАНОЇ ЛІТЕРАТУРИ
Т.Кватрани. Rational Rose 2000 и UML. Визуальное моделирование.- М.: ДМК Пресс, 2001. - 176 с.
С.А. Трофимов. Case-технологии: практическая робота в Rational Rose. Изд. 2-е. – М.: Бином-Пресс, 2002. – 288 с.
http://www.intuit.ru/department/se/ibmrrose/3/1.html
ДОДАТОК
1. Інформаційна система автоматизації роботи лікарняного закладу. Лікар має можливість проглянути лікарняну картку конкретного пацієнта і добавити туди дані. Лікар може направити пацієнта для вияснення діагнозу на аналізи, результати яких повинні бути видані лікареві. Пацієнт має можливість проглянути розклад прийому лікарів.
2. Інформаційна система фірми, яка займається торгівлею. Система повинна розрізняти великий гурт, дрібно гуртових і роздрібних покупців. Замовник має мати можливість проглянути наявність товарів і їх ціни. В системі повинні реєструватися поступлення товарів і продаж товарів. Система має давати можливість менеджеру фірми перевірити наявність товару і замовити його у відділу постачання, якщо його немає. Система має видавати інформацію касиру про те, яка ціна на даний товар.
3. Інформаційна система бібліотеки університету. В системі повинен бути організований доступ для читачів до електронних каталогів. Для студентів і працівників університету повинен бути доступним і електронний варіант текстів книг. Читачі бібліотеки повинні мати змогу оформити за допомогою системи замовлення на книгу. Система повинна вести облік книг виданих в читальний зал і на абонемент.
4. Інформаційна система автомобільного салону. Покупець повинен мати змогу переглянути каталог автомобілів, що продаються, і їх характеристики. Менеджер повинен мати інформацію про наявність відповідних автомобілів і можливість їх замовити у постачальника. Салон повинен надавати гарантійне сервісне обслуговування автомобілям, купленим у них. Страхова компанія оформляє страховку для купленого автомобіля.
5. Система зрошування поля. Після збору інформації про температуру, вологість, швидкість вітру, робиться аналіз і визначається кількість води, яка повинна бути подана для зрошення зрошувальною системою. Для кожного виду рослин повинен бути визначений відповідний режим зрошування агрономом.
6. Інформаційна система зоопарку. Система постачання по замовленню системи контролю повинна постачати відповідну кількість корму для тварин. Адміністрація зоопарку може придбати або продати ту чи іншу тварину. Система контролю повинна вести облік тварин, контролювати стан їхнього здоров’я. Вразі захворювання повинен бути викликаний ветеринар, який лікуватиме тварину.
7. Інформаційна система житлового будинку. Адміністрація будинку повинна вести облік людей, що проживають у будинку, а також висилати рахунок і отримувати кошти за послуги від тих, хто проживає у будинку. В разі виникнення поломок, адміністрація повинна викликати майстрів, які б усунули поломку. Майстри отримають гроші за роботу від адміністрації. Ті хто проживають у будинку повинні інформувати адміністрацію про поломки.
8. Інформаційна система обліку працівників заводу. Адміністрація повинна мати можливість переглядати результати роботи робітників. Повинна мати можливість звільняти і набирати на роботу робітників. Адміністрація отримує зарплату від відділу бухгалтерії. Робітники теж отримують зарплату. Адміністрація може давати вказівки бухгалтерії преміювати тих чи інших робітників. Робітник може звільнитися з роботи написавши заяву у відділі кадрів.
9. Інформаційна система редакції газети. Повинна зберігатися інформація про видані газети. Не видані газети спочатку подаються у відділ редагування, де вони редагуються. Матеріали отримуються від журналістів і від дописувачів. Журналісти отримують зарплату, дописувачі ні. Газета після редагування подається на друк у видавництво.
10. Інформаційна система банку. Банк надає кредити фізичним і юридичним особам. Система повинна відслідковувати і інформувати банк про тих, хто не сплатив у відповідний термін місячної плати за кредит. Клієнти мають мати можливість переглянути стан свого рахунку, зняти з нього кошти, або покласти кошти на рахунок. Банк подає в суд, якщо боржник не сплачує кредиту у відповідні терміни.
11. Інформаційна система реєстрації автомобілів та дорожнього руху ДАІ. Система повинна дозволяти вести як облік транспортних засобів, так дані про порушників, ДТП, водіїв і т.д.
12. Інформаційна система аеропорту. Пасажир має мати можливість переглянути розклад рейсів і ціну квитка. Він має мати можливість замовити і оплатити квиток. В систему реєстрації аеропорту має поступати інформація про польоти і екіпаж і вона має формувати розклад польотів. Для кожного літака повинен бути список членів екіпажу. Для кожного рейсу повинна бути можливість перевірити наявність непроданих квитків і їх кількість та місця.
13. Інформаційна система автоматизованого укладання розкладу учбового закладу. Викладачі подають інформацію про предмети, які вони будуть читати. Кафедри подають інформацію про те, які аудиторії і скільки аудиторій в них є, і які групи закріплені за кафедрою. Повинна бути можливість переглянути розклад для конкретної групи. Повинна бути можливість переглянути список пар для конкретних викладачів. З вхідної інформації повинен бути сформований розклад. Повинна бути можливість корегувати розклад, а також отримати список пар (група, дисципліна, дата, час) для конкретної аудиторії.
14. Інформаційна система обліку поселень та бронювань у готелі. Клієнт готелю має мати змогу переглянути список вільних номерів і їх характеристики, теж повинен мати змогу забронювати місце на відповідне число, якщо номер вільний, та замовити список послуг. Для конкретного номеру на конкретне число повинна відображатися ціна найму. Реєстратор повинен мати змогу проглянути таблицю вільних місць на відповідне число. Також він повинен мати змогу забронювати відповідне місце, або здійснити поселення у відповідний номер. Система обслуговування (ресторан, та інші служби) повинні отримувати інформацію про те, які послуги замовлені, і в якому номері зупинився замовник.
15. Інформаційна система для автоматизації діяльності фірми-ріелтора. Для клієнта повинна бути можливість проглянути інформацію про квартири, що продаються чи здаються в оренду. Для працівника фірми повинна бути доступна контактна інформація власника, та ціна тої чи іншої квартири або її оренди. Для квартир, які здаються в оренду, повинен бути орієнтовний час, на який здається квартира. Повинна бути змога отримати квартири за ціною на них.
16. Інформаційна система для апарату поповнення рахунку. Користувач повинен мати можливість подати в апарат суму, на яку він хоче поповнити рахунок, обрати оператора зв’язку і ввести свій номер. Система поповнення рахунку повинна перерахувати гроші відповідному оператору зв’язку. Система поповнення рахунку повинна видати клієнту чек – підтвердження поповнення рахунку.
17. Інформаційна система обліку абонентів оператора мобільного зв’язку. Абонент має мати можливість здійснювати розмови, відсилати СМС, ММС, а система оплати повинна тарифікувати дзвінки і знімати з рахунку кошти. Абонент має мати змогу поповнити рахунок. Оператор забороняє здійснення вихідних дзвінків, якщо система оплати повідомляє його про те, що в абонента недостатньо грошей. Оператор повідомляє абонента про малу суму коштів на рахунку, якщо сума на рахунку менша зазначеного значення. Інформація про абонентів повинна зберігатися (зокрема номер абонента і сума на рахунку).
18. Інформаційна система підприємства постачання води. Система обліку користувачів отримує, зберігає та подає в систему оплати інформацію про споживання води. Користувачі послугою, які мають лічильник повинні самі повідомляти покази лічильника в систему обліку користувачів. Для користувачів, які не мають лічильника система обліку направляє інформацію по стандартному тарифу, відповідно до кількості проживаючих, у відділ оплати. Відділ оплати згідно з інформацією, яка подається відділом обліку, направляє рахунки на оплату користувачам з лічильником та без лічильника. Користувачі повинні здійснити оплату. Користувачі повідомляють систему обслуговування про поломки мережі водопостачання. Система обслуговування повинна усунути несправність і повідомити про це відділ обліку.
19. Інформаційна система тролейбусного парку. Служба відповідальна за встановлення графіку руху повинна отримувати інформацію від завідуючого рухомим складом про кількість тролейбусів. На основі інформації про кількість тролейбусів та інформації про маршрут (вважається що вона відома) встановити графік руху тролейбусів. Кожен водій повинен отримати графік роботи від служби відповідальної за розклад руху. Повинна бути можливість отримати графік руху і водіїв для конкретного тролейбуса в конкретний день. Служба відповідальна за ремонт повинна бути проінформована в разі поломки.
20. Інформаційна система форуму. Адміністратор керує правами користувачів форуму. Він може блокувати користувачів, які шкодять роботі форуму. Він повинен мати змогу отримати графік відвідуваності форуму його користувачами, має права для зміни і видалення повідомлень і тем. Система повинна реєструвати нових користувачів. Модератори теж мають права на редагування повідомлень і їх видалення. Звичайні користувачі можуть лише створювати повідомлення і теми, але не можуть редагувати повідомлення, крім своїх повідомлень.
21. Інформаційна система обліку користувачів провайдера Інтернету. Для доступу в Інтернет є три різних тарифних плани на трьох різних швидкостях. Система по логіну користувача повинна визначати, який тарифний план він замовив і відповідно до того провайдер надає йому доступ на замовленій швидкості. Система повинна реагувати на те, чи заплатив за послугу той чи інший користувач. Для того повинен бути перевірено чи приходили перерахування від цього користувача. Якщо він не заплатив за послугу, то доступ повинен бути заблокований.
22. Інформаційна система електронного телефонного довідника. Система повинна зберігати інформацію про адреси та телефони фізичних та юридичних осіб. Користувач повинен мати змогу отримати інформацію по запиту по адресі, по прізвищі, імені, по-батькові. Адміністратор повинен мати можливість вносити зміни, якщо міняється адреса, чи телефон тої чи іншої особи, додати новий запис до бази даних при появі нового абонента з новим номером. Система повинна надавати змогу користувачам інформувати адміністратора при знайденні ними помилки в даних системи.
23. Інформаційна система комп’ютерної системи кафедри. До системи повинні мати доступ студенти та викладачі, та інженери з різними правами (абстрагуватимемся та не будемо уточнювати), які надає адміністратор. При порушенні правил користувачами адміністратор має право їх заблокувати. Адміністратор повинен мати змогу переглянути дані про те хто, на якому комп’ютері і коли заходив у систему. Адміністратор має змогу створити новий обліковий запис для нового користувача.
24. Інформаційна система торгової фірми. Служба постачання вносить інформацію про прибуття товару і його кількість. Менеджер має можливість замовляти товар і переглядати його наявність і кількість на складі. Торговий агент повинен мати можливість доступатися до інформації про наявність і кількість товару на складі і відправляти замовлення на постачання в службу дистрибуції. Дистрибуція повинна мати можливість переглядати інформацію про замовлення, що поступили і виконувати доставку товару.
25. Інформаційна система підтримання мікроклімату в приміщенні. Значення температури та відносної вологості в приміщенні поступає з відповідних датчиків. Користувач системи має змогу встановити значення температури та відносної вологості, які потрібно підтримувати. Система проаналізувавши дані дає команду пристроям, які керують відносною вологістю та температурою.
26. Інформаційна система обліку використаної електроенергії. Відділ збору показів лічильників збирає і вносить інформацію про покази лічильників користувачів послугою. Система зберігає інформацію про тарифікацію світла та пільги користувачів. Відповідно до тарифів нараховується плата за електроенергію, яка направляється в фінансовий відділ. Фінансовий відділ відслідковує злісних боржників і направляє інформацію про них у відділ, який займається відключенням злісних боржників. Відділ контролю здійснює контроль за несанкціонованим підключенням до електромережі і вносить в систему дані про порушників. Ця інформація надходить у відділ, який займається відключенням, який відключає цих користувачів.
27. Інформаційна система торгової фірми. Служба постачання вносить інформацію про отриманий товар. Менеджер повинен мати можливість переглянути інформацію про наявність і кількість товару і здійснити замовлення. При здійсненні замовлення інформація про замовлення повинна поступати в бухгалтерію і бухгалтерія повинна оплатити замовлення. При відсутності коштів бухгалтерія може відмінити замовлення. Бухгал...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора