Проектування інформаційної системи засобами Rational Rose - Студопедія
Компанія Rational Software є лідируючою в галузі створення методологій та програмних рішень, орієнтованих на програмістів, аналітиків, тестувальників. Спектр програмного забезпечення повністю покриває потребу всіх учасників проекту: від аналітиків до розробників і впроваджувачів.
У цій роботі для розробки програми обліку реалізації товару був використаний програмний продукт IBM Rational Rose Enterprise Edition.
Сімейство продуктів IBM Rational Rose призначене для розробки програм на основі Unified Modeling Language (UML). Архітектори, аналітики, проектувальники програмного забезпечення та баз даних та розробники систем можуть використовувати це сімейство продуктів для створення візуальних моделей архітектури програмного забезпечення, баз даних, вимог програми та багаторазових ресурсів, а також визначення зв'язку на рівні керівництва.
Rational Rose, на відміну від подібних засобів проектування, здатна проектувати системи будь-якої складності, тобто інструментарій програми допускає як високорівневе (абстрактне) уявлення (наприклад, схема автоматизації підприємства), так і низькорівневе проектування (інтерфейс програми, схема бази даних, частковий опис класів).
Будучи об'єктно-орієнтованим інструментом моделювання, Rational Rose базується на UML (Universal Modeling Language) – універсальній мові моделювання, яка була розроблена компанією Rational саме з метою створення найбільш оптимальної та універсальної мови для опису як предметної галузі, так і конкретного завдання у програмуванні. Будь-яке завдання програмується за допомогою певних діаграм. UML підтримує побудовунаступних діаграм:
- Activity diagram (діаграми описів технологій, процесів, функцій);
- Use case diagram (діаграми функцій);
- Class diagram (діаграми класів);
- State diagram (діаграми станів);
- Sequence diagram (діаграми послідовностей дій);
- Collaboration diagram (діаграми взаємодій);
- Component diagram (діаграми компонент);
- Deployment diagram (діаграми топології).
Основними елементами мови UML є сутності, відносини та діаграми.
Сутності – це абстракції, які є основними об'єктно орієнтованими елементами мови. З їхньою допомогою можна створювати коректні моделі. У UML є чотири типи сутностей:
Структурні сутності – це іменники в моделях мовою UML. Зазвичай, вони є статичні частини моделі, відповідні концептуальним чи фізичним елементам системи.
Існує сім різновидів структурних сутностей:
- Клас (class) – це опис сукупності об'єктів із загальними атрибутами, операціями стосунками та семантикою. Графічно клас зображується у вигляді прямокутника, в якому записані його ім'я, атрибути та операції;
- Інтерфейс (interface) – це сукупність операцій, що визначають певну службу (сервіс, набір послуг), які надає клас чи компонент. На діаграмах інтерфейс зображується як кола, під яким вказується його ім'я. Інтерфейс дуже рідко існує сам по собі - зазвичай він приєднується до реалізує його класу або компоненту;
- Кооперація (collaboration) визначає взаємодію, вона є сукупністю ролей та інших елементів, які, працюючи разом, справляють деякий кооперативний ефект,що не зводиться до звичайно суми доданків. Графічно кооперація зображується як еліпса, який обмежується пунктиром, всередині зазвичай укладено лише ім'я;
- Прецедент (use case) – це опис послідовності виконуваних системою дій, яка виробляє спостерігається результат, значимий якогось певного актора (actor). Графічно прецедент теж зображується у вигляді еліпса, лише обмеженого безперервною лінією, що зазвичай містить лише його ім'я;
- Активним класом (active class) називається клас, об'єкти якого залучені до одного чи кілька процесів, чи ниток (threads), і тому можуть ініціювати керуючий вплив. Графічно активний клас зображується як і простий клас, але обмежується прямокутником, який малюється жирною лінією, і включає ім'я, атрибути та операції;
- Компонент (component) – це фізична частина системи, що замінюється, яка відповідає деякому набору інтерфейсів і забезпечує його реалізацію. Графічно компонент зображується у вигляді прямокутника з вкладками, що містить тільки ім'я;
- Вузол (node) – це елемент реальної (фізичної) системи, який існує під час функціонування програмного продукту і є деяким обчислювальним ресурсом, що зазвичай володіє як мінімум деяким обсягом пам'яті, а часто ще й можливістю обробки. Графічно для зображення вузла використовується куб, що містить тільки ім'я вузла.
Поведінкові сутності (behavioral things) є динамічними компонентами моделі UML. Це дієслова мови, вони описують поведінку моделі у часі та просторі. Існує всього два основних типи поведінкових сутностей:
- Взаємодія (interaction) - це поведінка, суть якої полягає в обмініповідомленнями (messages) між об'єктами у межах конкретного контексту задля досягнення певної мети. З допомогою взаємодії можна описати як окрему операцію, і поведінка сукупності об'єктів. Взаємодія передбачає низку інших елементів, як-от повідомлення, послідовності дій (поведінка, ініційоване повідомленнями) і зв'язку (між об'єктами). Графічно повідомлення відображається у вигляді стрілки. Над якою майже завжди пишеться ім'я відповідної операції;
- Автомат (state machine) – алгоритм поведінки, визначальний послідовність станів, якими об'єкт чи взаємодія проходять протягом свого життєвого циклу у відповідь різні події, і навіть реакцію ці події. З допомогою автоматів описуються поведінка окремого класу чи кооперації класів. З автоматом пов'язаний ряд інших елементів: стани, переходи з одного стану в інший, події - сутності переходи, що ініціюють, і види дій - реакція на переходи. Графічно стан зображується у вигляді прямокутника із закругленими кутами, що містить ім'я та, можливо, проміжні стани.
Групуючі сутності є частинами моделі UML, що організують. Це блоки, куди можна розкласти модель. Така первинна сутність є у єдиному екземплярі – це пакет.
Пакети (packages) є універсальний механізм організації елементів групи. У пакет можна помістити структурні, поведінкові та інші сутності, що групують. На відміну від компонентів, які реально існують під час роботи програми, пакети мають суто концептуальний характер, тобто існують лише у процесі розробки. Для зображення пакета використовується піктограма папки із закладкою, що містить лише ім'я, але іноді й вміст.
Відносини – це засоби мови UML, за допомогою яких пов'язують різні сутності. Існує 4 типи відносин:
Залежність (dependency) – це семантичне відношення між двома сутностями, у якому зміна однієї з них, незалежної, може спричинити семантику інший, залежної. Графічно для зображення залежності використовують пунктирну лінію, зазвичай, зі стрілкою, яка може містити мітку
Асоціація (association) – структурне відношення, що описує сукупність зв'язків, де під зв'язком розуміється певний смисловий зв'язок між об'єктами. Різновидом асоціації є агрегування (aggregation) - так називається структурне відношення між цілим та його частинами. Графічно асоціація зображується у вигляді лінії (іноді завершується стрілкою або містить мітку), поряд з якою можуть бути додаткові позначення, наприклад кратність та імена ролей.
Узагальнення (generalization) – це ставлення "спеціалізація/узагальнення", у якому об'єкт спеціалізованого елемента (нащадок) може бути підставлений замість об'єкта узагальненого елемента (батька, предка). Як і належить в об'єктно-орієнтованому програмуванні, нащадок (child) успадковує структуру та поведінку свого предка (parent). Графічно відношення узагальнення зображується у вигляді лінії із незафарбованою стрілкою, що вказує на предка.
Реалізація (realization) – це семантичне відношення між класифікаторами, коли один класифікатор визначає зобов'язання, а інший гарантує його виконання. Відношення реалізації зустрічаються у двох випадках: по-перше, між інтерфейсами та реалізуючими їх класами або компонентами, а по-друге, між прецедентами та реалізуючими їх коопераціями. Відношення реалізації зображується у вигляді пунктирної лінії із незафарбованоюстрілкою, як щось середнє між відносинами узагальнення та залежності.
Діаграми є пов'язані графи, у вершинах яких є сутності, а ребрами є відносини.
Діаграми варіантів використання описують функціональне призначення системи чи те, що повинна робити. На діаграмах варіантів використання зображуються актори та варіанти використання, між якими існують стосунки. Дана діаграма дозволяє створити перелік операцій, які виконує система. На основі неї створюється список вимог до системи, і визначаються функції, що виконуються (рис. 1).
Рис.1. Діаграма варіантів використання ТОВ «Світ Комп'ютерів»
На даній діаграмі варіантів використання зображені актори, варіанти використання та відносини між ними для фірми ТОВ "Світ Комп'ютерів".
Актором називається будь-який об'єкт, суб'єкт чи система, що взаємодіє з модельованою бізнес-системою ззовні для досягнення своїх цілей або вирішення певних завдань. Актори взаємодіють із системою за допомогою передачі та прийому повідомлень від варіантів використання.
Варіант використання служить описи сервісів, які система надає актору.
Акторами на даній діаграмі є ключові об'єкти фірми, а також постачальник, директор, менеджер та клієнт. Варіантами використання будуть ті дії, які виконують відповідні актори.
На даній діаграмі розглядається послідовність процесів оформлення замовлення на товар у постачальників (рис. 2).
Рис.2. Діаграма взаємодії для виконання замовлень
Діаграма послідовності є одним з різновидів діаграм взаємодії і призначена для моделювання взаємодії об'єктів системичасу, а також обміну повідомленнями між ними.
Головна особливість діаграми кооперації полягає у можливості графічно подати не тільки послідовність взаємодії, а й усі структурні відносини між об'єктами, що беруть участь у цій взаємодії (рис. 3).
На діаграмі кооперації у вигляді актори зображені об'єкти, що беруть участь у взаємодії, які містять ім'я об'єкта. Між об'єктами встановлені асоціації як різних сполучних ліній. Потоки повідомлень представлені у вигляді сполучних ліній між об'єктами, над якими розташовується стрілка із зазначенням напрямку, імені повідомлення та порядкового номера у загальній послідовності ініціалізації повідомлень. Судячи з діаграми, можемо сказати, що завантаженість процесів проходить поступово.
На відміну від діаграми послідовності, на діаграмі кооперації зображені лише відносини між об'єктами, що грають певні ролі у взаємодії. Діаграма кооперації сприяє більш повному розумінню особливостей реалізації функцій системи, хоча й може містити всю інформацію, необхідну реалізації.
В результаті використання інструменту Rational Rose побудовано діаграми, які показали взаємодію об'єктів проектованої системи та їх послідовність.
Глава II. Функціональне проектування інформаційної системи ТОВ "Світ Комп'ютерів"
Чи не знайшли те, що шукали? Скористайтеся пошуком: