загрузка...
загрузка...
На головну

Функціональні особливості Rational Rose

  1. I. Особливості хірургії дитячого віку
  2. I. Особливості експлуатації родовищ
  3. II. Об'єктивні методи дослідження органів дихання. Особливості загального огляду. Місцевий огляд грудної клітки.
  4. II. Об'єктивні методи дослідження ендокринної системи. Особливості загального огляду.
  5. II.6.3) Особливості категорії юридичної особи.
  6. II. Інструментальні методи дослідження органів кровообігу. Функціональні методи дослідження.
  7. II. Об'єктивні методи дослідження органів жовчовиділення і підшлункової залози. Особливості загального огляду. Місцевий огляд живота. Діагностичне значення результатів огляду.

За час свого життя CASE-засіб Rational Rose змінювався і стало потужним засобом аналізу, моделювання та розробки систем. Нині мова UML став технологічною базою візуалізації і розробки програм, і це дало йому популярність і стратегічну перспективність. У Rational Rose є програмні інструментарії, що відрізняються діапазоном реалізованих можливостей.

Найбільш багата можливостями модифікація дозволяє здійснювати:

· Інтеграцію з MS Visual Studio 6 з підтримкою прямого і зворотного генерації кодів і діаграм VB 6, Visual C ++ 6, Visual J ++ 6, PowerBuilder (ATL-Microsoft Active Template Library, Data Connections, DHTML, Web-Classes).

· Підтримку технологій ADO (ActiveX Data Objects) і MTS (Microsoft Transaction Server) на рівні шаблонів і вихідного коду, а також елементів стратегічної технології Microsoft - СОМ + (DCOM).

· Випуск проектної документації, генерацію програмного коду стандарту MS Visual C ++, HTML-форматування проекту для Web-публікації і інтеграцію з іншими інструментами ООРП, базами даних і компонентами MS Office.

· Безпосередню роботу з бібліотеками форматів DLL, OCX, TLB і виконуваними модулями EXE.

· Підтримку CORBA 2.2 з технологією компонентної розробки додатків CBD (Component-Based Development), мовами визначення даних DDL (Data Definition Language) і інтерфейсу IDL (Interface Definition Language).

· Підтримку середовища розробки Java-додатків JDK 1.2 з прямого і зворотного генерацією класів Java формату JAR і роботою з файлами форматів CAB і ZIP.

За допомогою Rational Rose можна виконувати наступні функції:

· Розробити функціональну модель системи.

· Створити структурну схему системи або її топологію.

· Розробити модель поведінки системи, тобто динаміку.

· Розробити створювати логічне уявлення системи, на основі якого створюється вихідний код описаних класів.

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

· Згенерувати на одному з найбільш використовуваних мов програмування програмний код, який представляє собою опис набору класів, що описують проектовану систему. Rational Rose не генерує повністю виконуваний код, а генеруєте розписані класів на обраною мовою програмування.

· Сформувати моделі програмної системи на основі вже написаного коду.

· Змоделювати WEB-систему.

В результаті можна зробити висновок про те, що за допомогою Rational Rose можна проводити аналіз предметної області та здійснювати розробки програмних систем і бізнес процесів, а також проводити реінжиніринг діючих систем.

Робота над проектом включає використання спеціального браузера Rational Rose, виклик в вікно потрібної діаграми і додавання в неї елементів графіки, з встановленням відносин між цими елементами, їх специфікації і документування. За перевіркою узгодженості специфікацій елементів моделі і моделі в цілому генерують текст програмного коду на обраною мовою програмування.

Робота з графічними елементами на діаграмі аналогічна реалізованої в інших середовищах візуального програмування. Видалення елемента з діаграми додатково вимагає його видалення з моделі проекту.

Для видалення елемента не тільки з будь-якої діаграми, а й з моделі в цілому необхідно виділити видаляється елемент на діаграмі і скористатися пунктом меню Edit- »DeIete from Model.

Створення проекту в середовищі Rational Rose починається з аналізу проблеми і побудови діаграми варіантів використання, яка описує функціональність проектованої системи.

Візуальне моделювання в UML - це поуровневого спуск від абстрактної концептуальної моделі вихідної системи до логічної, а далі до до фізичної моделі відповідної програмної системи. В таких цілях спочатку будують модель як діаграму варіантів використання (Use case diagram) для опису функціонального призначення системи, як її концептуальної моделі в процесі проектування.

Розробка діаграми варіантів використання потрібна для:

· Визначення меж і контексту моделюється предметної області на початку проектування системи;

· Формулювання вимог до функціонала системи;

· Створення концептуальної вихідної моделі системи для деталізації далі у вигляді логічних і фізичних моделей;

· Підготовки вихідної документації для розробників системи, її замовників та користувачів.

У цій діаграмі проектована система складається з безлічі сутностей (акторів), що взаємодіють з системою за допомогою т.зв. варіантів використання. Дійова особа (актор, actor) - будь-яка сутність, ззовні взаємодіє з системою: людина, апарат, програма, інша система. Актор служить джерелом впливу на модель системи по опреденію розробника. Варіант використання (use case) описує послуги, що надаються акторові системою, тобто кожен варіант використання визначає набір дій системи в діалозі з актором. При цьому реалізація взаємодії акторів з системою ще не визначається.

Діаграма варіантів використання - високорівневе представлення моделі, і вона не містить багато акторів і варіантів використання. Далі нові елементи можна включити чи виключити з діаграми. Середу повідомив розробнику, якщо для пари елементів обраний неприпустимий вид зв'язку; такий зв'язок на діаграму додана не буде.

діаграма класів (Class diagram) представляє статичну структуру моделі системи в термінології класів ООП. Ця діаграма відображає взаємозв'язок між сутностями предметної області (об'єктами і підсистемами), описує їх внутрішню структуру і типи відносин. На ній не вказують інформацію про тимчасові аспектах роботи системи. Отже, діаграма класів - розвиток концептуальної моделі системи.

Діаграма класів - основне логічне представлення моделі, детально інформує про внутрішній устрій об'єктно-орієнтованої системи. Аналогічно додають і видаляють елементи, і кожен клас має специфікацію з інформацією про його атрибутах і операціях, а видимість атрибутів і операцій зображена спеціальними піктограмами (рис. 5.1).

Мал. 5.1. Графічне зображення діаграми класів в Rational Rose.

Піктограми стоять перед ім'ям атрибута або операції і мають сенс:

відкритий (Public) - встановлюється за умовчанням (атрибут 1 в класі 1) і видно всім іншим класам моделі, які можуть бачити і змінювати його значення. В нотації UML відкритого атрибуту відповідає знак "+".

захищений (Protected, атрибут 2 в класі 1), який можна переглянути і змінити з самого класу чи з його нащадків; такому атрибуту відповідає знак "#".

закритий (Private, атрибут 3 в класі 1) видно тільки класу, в якому він визначений, і йому відповідає знак "-".

пакетний (Implemented) атрибут є загальним тільки в своєму пакеті і не має піктограми в UML.

Аналогічні піктограми є і для операцій класу.

Через пункт контекстного меню Open Specification (Відкрити специфікацію) можна призначити стереотип і задати тип даних і початкові значення окремих атрибутів класу - в списку пропонується вибір відповідних значень. У вкладці Operations (Операції) для операцій класу задають тип результату (що повертається класу), додають аргументи, призначають стереотип, визначають протокол і розмір, задають виняткові ситуації та інші властивості.

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

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

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

при розгляді діаграми станів, Слід зазначити, що в середовищі Rational Rose цей тип діаграм відноситься тільки до окремого класу. Для того щоб побудувати діаграму станів для класу, його спочатку необхідно створити і уточняти. Після цього виділити на діаграмі класів або в браузері.

Ця діаграма, головним чином, потрібна для опісатнія можливих послідовностей станів і переходів, спільно характеризують поведінку елемента моделі в його життєвому циклі. Діаграма станів виходячи з специфікації реакції сутностей на сприйняття деяких конкретних подій представляє їх динамічну поведінку. Системи, що реагують на зовнішні дії, називають реактивними, а якщо дії відбуваються в випадкові моменти часу, то поведінка моделі асинхронно. Діаграми станів також застосовують для специфікації функціональності варіантів використання, акторів, підсистем, операцій, методів та інших компонент моделей. Примітивний приклад уявлення станів і переходів на базі автоматів - працездатність технічного пристрою. У ньому розглядають два стану :: "справно" і "несправне" і два переходи: "вихід з ладу" і "ремонт", що і зображено на діаграмі станів (рис. 5.2).

Мал. 5.2. Діаграми станів технічного пристрою.

Розглянемо діаграму станів на прикладі моделювання процесу роботи телефонного апарата (рис. 5.3).

Діаграма станів представляє один автомат з одним активним складовим станом. Поза цього стану є одне пасивний стан «очікування», в якому знаходиться справний і підключений до мережі телефонний апарат. З підняттям трубки телефон переходить в активний стан, а атомарний дію «подати сигнал» переводить телефон в початкове підстан активного стану.

Мал. 5.3. Діаграма станів роботи телефонного апарату.

Апарат, перебуваючи в стані «звуковий сигнал»; останній буде безперервно видаватися до моменту появи події-тригера «набір цифри (п)», але не більше 15 секунд з моменту підняття трубки. У першому випадку апарат буде здатний «набір», інакше - в стані «Кінець часу очікування». Це потрібно для зняття навантаження на мережу.

Якщо при наборі номера відбувається подія-тригер «набір цифри (п)» з умовою-сторожем «номер неповний», то, за відсутності в набраному номері необхідної кількості цифр, триває набір цифр в стані «набір». У разі повноти набраного номера йде перехід в стан «невірний номер» або «з'єднання». У першому випадку (умова-сторож «невірний» істинно) складене стан покидается, інакше відбувається спроба з'єднання по набраним номером.

Апарат абонента може виявитися зайнятий (перехід в стан «зайнято») або вільний (перехід в стан «дзвінок у абонента»). У першому випадку можливе повторення дозвону після виходу з складеного стану. У другому випадку, якщо умова-сторож «розмова доступний» істинно (абонент зняв трубку), починається сама розмова. Після закінчення розмови і виконання сторожового умови-сторожа «підтвердження» апарат переходить в стан «очікування».

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

Для моделювання операцій в мові UML служать діаграми діяльності, є кожне стан на яких відповідає виконанню елементарної операції, а перехід в інший стан йде тільки при завершенні цієї операції в попередньому стані. Діаграму діяльності представляють у вигляді графа діяльності, де вершини - стану дії, а дуги - переходи між станами дії. Тому діаграми діяльності суть окремий випадок діаграм станів.

Розглянемо частину алгоритму обчислення дійсних коренів квадратного рівняння канонічного виду: а * х * х + b * х + с = 0. Якщо його дискримінант від'ємний, рівняння не має дійсних рішень, і процес припиняється; інакше коріння можна отримати по конкретної формулою.

Фрагмент процедури обчислення коренів можна уявити діаграмою діяльності з трьома станами дії і розгалуженням (рис. 5.4). Кожен перехід зі стану "Обчислити дискримінант" умова-сторож визначає по знаку дискримінанту.

Мал. 5.4. Фрагмент діаграми діяльності для обчислення коренів квадратного рівняння.

діаграми взаємодії використовують при моделюванні взаємодії об'єктів в UML.

Взаємодії об'єктів відбуваються в часі; для опису процесів прийому і передачі повідомлень між об'єктами застосовують діаграму послідовності.

Розглянемо діаграми послідовності при моделюванні телефонної розмови по звичайній телефонній мережі. Об'єкти в цьому прикладі - два абонента а й b, два телефонні апарати c і d, комутатор і сама розмова як процес; комутатор і розмова суть анонімні об'єкти.

Спочатку об'єкти розташовують на передбачуваної діаграмі (рис. 5.5.). Абоненти розглядаються як актори, причому перший (а) активний, а другий (b) - пасивний. Перший отримує фокус управління з появою в системі, а у другого є тільки лінія життя. Комутатор теж постійно активний, що показано його фокусом управління. Об'єкт розмови з'являється після установки з'єднання і зникає з його припиненням, чому він буде зображений на цій же діаграмі пізніше.

Рис 5.5. Перша частина діаграми послідовності для моделі телефонної розмови.

Взаємодії в системі починаються з підняття трубки апарату першим абонентом. Це повідомлення активізує апарату «c», і викликає звуковий сигнал в трубку першого абонента. Друга дія, що ініціюється першим абонентом - набір цифр номера, що представлено ітеративним повідомленням зі знаком "*" зліва від імені.

Відповідь на дзвінок і набір цифр номера - фізичні дії і зображені простмі асинхронними повідомленнями. Після набору цифр апарат «з» рекурсивно посилає комутаційні імпульси на комутатор, який ініціює новий об'єкт - телефонна розмова. Доповнена частина діаграми послідовності дана на рис. 5.6.

Анонімний об'єкт "розмова" отримує фокус активності і посилає повідомлення апарату «d» для виконання сповіщення про виклики. При цьому другий абонент знімає трубку (це асинхронне повідомлення), і встановлюється пряме з'єднання між абонентами «а» і «b2. Об'єкт "розмова" знищується після опускання трубок абонентами. Діаграма послідовності може включати тимчасові обмеження і коментарі (рис. 5.7.).

Мал. 5.6. Доповнення діаграми послідовності для моделі телефонної розмови.

Мал. 5.7. Діаграма послідовності для моделі телефонної розмови.

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

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

Діаграма компонент розробляється для:

  • Візуалізації загальної структури системи.
  • Специфікації реалізованого варіанта системи.
  • Забезпечення багаторазового використання окремих фрагментів моделі.
  • Уявлення концептуальної і фізичної схем інформаційних структур.

Загальна фізична структуризація системи доповнюється модель інтерфейсами і схемами інформаційних структур. Інтерфейси забезпечують узгодження різних частин системи. Включення в модель схем структур інформації зазвичай викликає опис відповідних баз даних.

На завершення побудови діаграми компонент пов'язаний встановлюють і включають в діаграму взаємозв'язку між компонентами і відносини реалізації. Ці відносини відображають аспекти фізичної реалізації системи, для чого використовують різні графічні зображення компонент.

Варіант фізичного представлення системи - діаграма розгортання (Розміщення), що застосовується для уявлення загальної конфігурації і топології розподіленої системи; вона містить розподіл компонент по вузлах системи. Вона показує фізичні з'єднання - маршрути передачі інформації між апаратними пристроями, що знаходяться в систему.

Діаграма розгортання містить графічні зображення пристроїв, процесів і зв'язків між ними. Відрізняючись від діаграм логічного представлення, діаграма розгортання одна для системи в цілому, повністю відображаючи особливості її реалізації. Цією діаграмою завершується процес ООАП для системи і її розробка зазвичай - останній етап специфікації моделі.

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

Після побудови моделей можливо скористатися одним з найбільш потужних властивостей середовища Rational Rose генерацією програмного коду. Генерація тексту програми на конкретній мові програмування залежить від встановленої версії Rational Rose, для чого:

1. Перевіряється модель.

2. Створюються компоненти реалізації класів.

3. Буде відображено класи на компоненти.

4. Встановлюють властивості генерації програмного коду.

5. Вибирають клас, компоненту або пакет.

6. Генерують програмний код.

Кожен з етапів може змінюватися в залежності від мови.

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

Для зворотного проектування в Rational Rose введений модуль Analyzer, що аналізує файл (на ADA, Basic, С, С ++, COM, DDL, XML та ін.) І перетворює його в файл візуальної моделі з розширенням mdl. Далі файл відкривається в візуальному режимі для модифікації з Rational Rose.

 



Попередня   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   Наступна

Підпакети Управління моделями. | Особливості опису метамоделі UML | Діаграма станів. | Особливості зображення діаграм UML | Use case diagram (діаграми прецедентів). | Deployment diagram (діаграма топології). | Activity diagram (діаграми активності). | Interaction diagram (діаграма взаємодії) | Collaboration diagram (діаграми співробітництва) | Class diagram (діаграма класів). |

загрузка...
© um.co.ua - учбові матеріали та реферати