Уніфікована мова моделювання UML

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Курсова робота студентки Боярчук Юлії Олегівни

Тема роботи “ Уніфікована мова моделювання UML”

ЗМІСТ

ВВЕДЕННЯ

1.УНІФІКОВАНА МОВА МОДЕЛЮВАННЯ UML

2.ЗМІСТОВИЙ ОГЛЯД ПРЕДМЕТНОЇ ОБЛАСТІ. ОСНОВНІ ВИМОГИ ДО СИСТЕМ

3. РОЗРОБКА МОДЕЛІ ПРОГРАМНОЇ СИСТЕМИ ЗАСОБАМИ UML

3.1 Вид з погляду прецедентів

3.2 Вид з погляду проектування

3.3 Вид з погляду реалізації

ВИСНОВОК

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

ВВЕДЕННЯ

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

Для моделювання й аналізу інформаційних систем використовують: Rational Rose, Oracle Designer, AllFusion ERwin Data Modeler, ARIS, Sybase PowerDesigner, AllFusion Process Modeler.

Rational Rose

Популярний засіб візуального моделювання об'єктно-орієнтованих інформаційних систем компанії Rational Software Corp. Робота продукту заснована на універсальній мові моделювання UML (Universal Modeling Language). Завдяки унікальній мові моделювання Rational Rose здатний вирішувати практично будь-які завдання в проектуванні інформаційних систем: від аналізу бізнес процесів до кодогенераціі певною мовою програмування. Тільки Rational Rose дозволяє розробляти як високорівневі, так і низькорівневі моделі, здійснюючи тим самим або абстрактне проектування, або логічне.

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

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

Rational Rose Modeler.Дана версія дозволить аналітикам і проектувальникам проводити аналіз бізнес-процесів і вибудовувати систему. Дана редакція передбачає не лише моделювання без кодогенераціі.Продукт буде цікавий проектувальникам систем і аналітикам.

Rational Rose Professional. Професійна редакція продукту. Має у своєму наборі весь спектр образотворчих засобів. Залежно від вибраної мови програмування здійснює пряме і зворотне проектування. Rose Professional замовляється тільки в певній конфігурації (наприклад, Rose Professional С + + або Rose Professional С + + DataModeler). Rational Rose Professional не створює 100% виконуваного коду. На виході розробник отримує шаблон інформаційної системи на певній мові програмування, яка згодом потрібно запрограмувати.Продукт спрямований як на аналітиків, так і на розробників.

Oracle Designer

Засіб моделювання, проектування та генерації програм, визначення схем баз даних. Основою Oracle Designer є центральний репозитарій, з яким може одночасно працювати декілька груп розробників. Застосування Oracle Designer істотно підвищує не тільки продуктивність розробки, але і дисципліну документування проектів. Дозволяє розробнику візуально сформувати бізнес вимоги проекту і перетворити їх у фізичне уявлення. За допомогою отриманих специфікацій, використовуючи набір «майстрів» можна швидко отримати працюючі додатки. Oracle Designer не змушує розробника слідувати заздалегідь визначеної схеми. Користувач сам вибирає підхід, який більшою мірою відповідає вимогам конкретної ситуації. Це може бути і документування ділових процесів в організації, і швидка розробка прототипу майбутньої системи. Деяким може бути цікава CASE методологія пропонована Oracle Designer. Таким чином Oracle Designer пропонує інтегрований набір засобів з якого розробник може вибрати краще для вирішення свого завдання.

AllFusion Process Modeler

AllFusion Process Modeler є засобом програмної підтримки моделювання в трьох методиках - IDEF0, DFDxiii, IDEF3xiv - і дозволяє будувати як гібридні функціональні моделі, що складаються з діаграм, розроблених в різних методиках, так і функціональні моделі монометодичні-у кожній із цих методик.IDEF3, на відміну від структурних IDEF0 і DFD, є методикою потокового моделювання.

Як IDEF0, так і DFD можуть бути декомпозировані в IDEF3

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

AllFusion Process Modeler дозволяє будувати кілька типів діаграм:

> стандартні діаграми у всіх трьох методиках моделювання(контекстна діаграма, діаграма декомпозиції);

>нестандартні діаграми(дерево вузлів, плавальна доріжка, тільки для демонстрації,організаційна діаграма, сценарії);

AllFusion ERwin Data Modeler

Уніфікує процес створення баз даних з використанням різних СКБД, документує і супроводжує вже існуючі напрацювання.

Серед функціональних можливостей AllFusion ERwin Data Modeler можна виділити наступні:

> підтримка декількох методик створення діаграм сутність-зв'язок, на основі яких згодом створюються системні об'єкти вибраної СУБД, а саме: американський стандарт IDEF1X, методика IE багато в чому подібна стандарту IDEF1X і спеціальна методика,що підтримує створення сховищ даних;

> пряме генерування (Forward engineer). Це функція створення системних об'єктів вибраного сервера бази даних на основі створеної в ERwin DM схеми даних;

> зворотне генерування (Reverse engineer). За допомогою цієї функції на основі існуючої бази даних створюється схема даних у ERwin, що дозволяє ефективно документувати існуючі бази даних;

> повне порівняння (Complete compare). Функція, що дозволяє порівнювати побудовані в ERwin DM схеми даних між собою, або схему даних з існуючою базою даних, внаслідок чого скорочується час, необхідний на супровід СКБД.

ARIS

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

Серед великої кількості можливих методів опису можна виділити наступні

>eEPC (англ. extended event-driven process chain) - метод опису процесів;

>ERM (англ. entity-relationship model) - модель «сутність-зв'язок» для опису структури даних;

>UML (англ. unified modeling language) - об'єктно-орієнтована мова моделювання.

Крім того, в ARIS передбачена можливість створення сценаріїв автоматизації складання різних аналітичних звітів, нормативних документів, нових моделей. Кожен сценарій являє собою підпрограму, що запускається в ARIS Toolset або безпосередньо на сервері ARIS. Сценарії пишуться на спеціальній мові програмування - SAX Basic. Для автоматизованого формування того чи іншого звіту в ARIS сценарії оперують даними з бази моделей, виокремлюючи з неї конкретні об'єкти і моделі.

У сімейство ARIS входять наступні модулі:

>ARIS Toolset- базове інструментальне середовище;

>ARIS Design- спрощена середа моделювання;

>ARIS Simulation-модуль динамічного імітаційного моделювання;

>ARIS Link for R / 3 - модуль, що забезпечує інтеграцію з репозиториієм R / 3;

>ARIS Analyzer for R / 3 - модуль перевірки створюваних моделей на відповідність методології SAP;

>ARIS Promt-модуль вартісного аналізу;

>додаткові модулі-інтерфейси, що забезпечують інтеграцію з системами Microsoft Project, ER / win, Designer/2000, IBM Flowmark (клас workflow), Staffware і т.д.

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

Sybase PowerDesigner

Sybase PowerDesigner має загальну структуру для об'єктно-орієнтованого моделювання на вдосконаленому мовою UML, який відповідає вимогам аналітиків, дизайнерів, розробників баз даних і прикладних програм, адміністраторів, а також більш ефективну підтримку групової розробки завдяки вдосконаленому сховищу.Серед особливостей можна відзначити гнучку архітектуру, яка інтегрує різноманітні методи моделювання - як широкі можливості UML, так і моделювання залежностей об'єкт / зв'язок, здатність успадковувати і відновлювати структурні схеми та алгоритми роботи на основі Java-технології, PowerBuilder і XML, розробку прикладних програм , бізнес-логіки з підтримкою постійних об'єктів і використанням діаграм класів UML, успадкування структур баз даних і відновлення структурної схеми і алгоритму роботи з вихідним текстів для реляційних баз даних.

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

1. УНІФІКОВАНА МОВА МОДЕЛЮВАННЯ UML

Більшість існуючих методів об'єктно-орієнтованого аналізу і проектування (ООАП) включають як мова моделювання, так і опис процесу моделювання. Мова моделювання - це нотація (в основному графічна), яка використовується методом для опису проектів.

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

Процес - це опис кроків, які необхідно виконати при розробці проекту.

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

Іншим принципом побудови моделей складних систем є принцип багатомодельності. Цей принцип є твердження про те, що ніяка єдина модель не може з достатнім ступенем адекватності описувати різні аспекти складної системи. Стосовно до методології ООП це означає, що досить повна модель складної системи допускає деяке число взаємопов'язаних уявлень (views), кожне з яких адекватно відображає деякий аспект поведінки або структури системи. При цьому найбільш загальними уявленнями складної системи прийнято вважати статичне і динамічне представлення, які в свою чергу можуть підрозділятися на інші більш приватні подання.) Феномен складної системи якраз і полягає в тому, що ніяке її єдине подання не є достатнім для адекватного вираження всіх особливостей моделюється.

Ще одним принципом прикладного системного аналізу є принцип ієрархічної побудови моделей складних систем. Цей принцип наказує розглядати процес побудови моделі на різних рівнях абстрагування або деталізації в рамках фіксованих представлень. При цьому вихідна або первісна модель складної системи має найбільш загальне уявлення (мета представлення). Така модель будується на початковому етапі проектування і може не містити багатьох деталей і аспектів модельованої системи.

Головними в розробці UML були наступні цілі:

> надати користувачам готовий до використання виразну мову візуального моделювання, що дозволяє розробляти осмислені моделі та обмінюватися ними;

> передбачити механізми розширюваності та спеціалізації для розширення базових концепцій;

> забезпечити незалежність від конкретних мов програмування і процесів розробки;

> забезпечити формальну основу для розуміння цієї мови моделювання (мова повинна бути одночасно точним і доступним для розуміння, без зайвого формалізму);

> стимулювати зростання ринку об'єктно-орієнтованих інструментальних засобів;

> інтегрувати кращий практичний досвід.

Мова UML знаходиться в процесі стандартизації, проведеному OMG (Object Management Group) - організацією зі стандартизації в області об'єктно-орієнтованих методів і технологій, в даний час прийнятий в якості стандартної мови моделювання і отримав широку підтримку в індустрії ПЗ.

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

UML містить стандартний набір діаграм і нотацій найрізноманітніших видів.

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

Діаграма-в деякому сенсі одна з проекцій системи. Як правило, за винятком найбільш тривіальних випадків, діаграми дають згорнуте представлення елементів, з яких складена система. Один і той же елемент може бути присутнім у всіхдіаграмах, або тільки в декількох (найпоширеніший варіант), або не бути присутнім в жодній (дуже рідко).

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

В UML виділяють такі типи діаграм:

> діаграми варіантів використання (usecase diagrams) - для моделювання бізнес-процесів організації (вимог до системи);

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

> діаграми поведінки системи (behaviordiagrams);

>діаграми взаємодії (interactiondiagrams)-для моделювання процесу обміну повідомленнями між об'єктами. Існують два види діаграм взаємодії: діаграми послідовності (sequencediagrams) і кооперативні діаграми (collaborationdiagrams). На діаграмах взаємодії представлені зв'язки між об'єктами; показані, зокрема, повідомлення, якими об'єкти можуть обмінюватися. Діаграми взаємодії відносяться до динамічного виду системи. При цьому діаграми послідовності відображають тимчасову упорядкованість повідомлень, а діаграми кооперації - структурну організацію обміну повідомленнями об'єктів. Ці діаграми є ізоморфними, тобто можуть бути перетворені одна в одну;

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

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

> діаграми реалізації (implementationdiagrams): діаграми компонентів (componentdiagrams) - для моделювання ієрархії компонентів (підсистем) системи; діаграми розміщення (deploymentdiagrams) - для моделювання фізичної архітектури системи. На діаграмі компонентів представлена організація сукупності компонентів і існуючі між ними залежності. Діаграми компонентів відносяться до статичного виду системи з точки зору реалізації. Вони можуть бути співвіднесені з діаграмами класів, так як компонент зазвичай відображається на один або декілька класів, інтерфейсів або кооперацій....

Переваги UML

>UML об'єктно-орієнтований, в результаті чого методи опису результатів аналізу та проектування семантично близькі до методів програмування на сучасних ОО-ма мовами;

>UML дозволяє описати систему практично з усіх можливих точок зору і різні аспекти поведінки системи;

>діаграми UML порівняно прості для читання після досить швидкого ознайомлення з його синтаксисом;

>UML розширює і дозволяє вводити власні текстові та графічні стереотипи, що сприяє його застосування не тільки в сфері програмної інженерії;

>UML отримала широке поширення і динамічно розвивається.

Недоліки UML

>надмірність мови. UML часто критикується, як невиправдано велика і складна. Вона включає багато надлишкових або практично не використаних діаграм і конструкцій;

>неточна семантика. Так як UML визначено комбінацією себе (абстрактний синтаксис), OCL (мовою опису обмежень - формальної перевірки правильності) і англійського (докладна семантика), то вона позбавлена скутості властивою мовам, точно певним техніками формального опису. У деяких випадках абстрактний синтаксис UML, OCL і англійський суперечать один одному, в інших випадках вони неповні. Неточність опису самого UML однаково відбивається на користувачах і постачальниках інструментів, приводячи до несумісності інструментів через унікальне трактування специфікацій;

> проблеми при вивченні та впровадженні. Вищеописані проблеми роблять проблематичним вивчення та впровадження UML, особливо коли керівництво насильно змушує використовувати UML інженерів за відсутності у них попередніх навичок;

> тільки код відображає код. Ще одна думка - що важливі робочі системи, а не красиві моделі. Як лаконічно висловився Джек Ривс, «The code is the design» («Код і є проект»). Відповідно з цією думкою, існує потреба у кращому способі написання ПЗ; UML цінується при підходах, які компілюють моделі для генерування вихідного або здійсненного коду. Однак цього все-таки може бути недостатньо, тому що UML не має властивостей повноти за Тьюрингу і будь згенерований код буде обмежений тим, що може розгледіти або припустити інтерпретує UML інструмент;

2. ЗМІСТОВИЙ ОГЛЯД ПРЕДМЕТНОЇ ОБЛАСТІ. ОСНОВНІ ВИМОГИ ДО СИСТЕМИ

Моделювання предметної області є одним з найбільш важливих етапів робіт при проектуванні програмних систем масштабу підприємства. В даний час для цілей моделювання предметної області на ринку програмних продуктів представлено широкий спектр CASE-засобів. Найбільш популярними в нашій країні CASE-засобами є Rational Rose, BPwin, Silverrun, Process Analyst. Моделювання предметної області в цих засобах має скоріше багато спільного, ніж відмінностей. Проте важливим, з нашої точки зору, є комплексність підходу і використання єдиної уніфікованої нотації, не тільки на етапі моделювання предметної області, але і на подальших етапах розробки програмної системи, як це має місце в CASERationalRose.

У цій курсовійі на конкретному прикладі демонструється можливий підхід до моделювання предметної області з використанням уніфікованої нотації, заснований на застосуванні уніфікованої мови моделювання (Unified Modeling Language) (UML), і гармонійно поєднує в собі переваги структурних і об'єктних методів проектування в CASE Rational Rose. Отже, основними завданнями при моделюванні предметної області є опис:

>бізнес-процесів підприємства;

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

>бізнес-сутностей;

>сценаріїв виконання бізнес-функцій, що підлягають автоматизації;

>станів бізнес- сутностей;

>бізнес-правил.

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

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

>відповідність парадигми діаграми діяльності поданням користувачів про бізнес-процесі на рівні зв'язків з управління, а не за інформацією як, наприклад, в BPwin;

>чітке рольове вираз відповідальностей за ту чи іншу діяльність;

>можливість суміщення в діаграмах опис документів, пов'язаних з діяльністю та їх станів;

>розвинена нотація опису станів бізнес-сутностей (при використанні об'єктів).

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

Опис предметної області з використанням UML добре сприймається експертами предметної області і для розуміння представлених їм на розгляд моделей не вимагає ніякої спеціальної підготовки.

3. РОЗРОБКА МОДЕЛІ ПРОГРАМНОЇ СИСТЕМИ ЗАСОБАМИ UML

моделювання інформаційний система програмний

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

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

UML включає дев'ять видів діаграм:

>діаграми класів;

>діаграми об'єктів;

>діаграми Use Case (діаграми прецедентів);

>діаграми послідовності;

>діаграми співпраці (кооперації);

>діаграми схем станів;

>діаграми діяльності;

>компонентні діаграми;

>діаграми розміщення (розгортання).

UseCaseDiagram(діаграмипрецедентів)

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

Кожна така діаграма або, як її зазвичай називають, кожен Use case - це опис сценарію поведінки,якого дотримуються діючі особи (Actors). Даний тип діаграм використовується при описі бізнес процесів автоматизується предметної області, визначенні вимог до майбутньої програмної системи. Відображає об'єкти як системи, так і предметної області та завдання, ними виконуються.

DeploymentDiagram(діаграми розгортання)

Цей вид діаграм призначений для аналізу апаратної частини системи, тобто «заліза», а не програм. У прямому перекладі з англійської означає Deployment «розгортання», але термін «топологія» точніше відображає сутність цього типу діаграм.

Для кожної моделі створюється тільки одна така діаграма, що відображає процесори (Processor),пристрої (Device) та їх сполуки.

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

State Maсhine diagram (діаграми станів)

Кожен об'єкт системи, що володіє певним поведінкою, може знаходиться в певних станах, переходити зі стану в стан, здійснюючи певні дії в процесі реалізації сценарію поведінки об'єкта. Поведінка більшості об'єктів реальних систем можна уявити з точки зору теорії кінцевих автоматів, тобто поведінка об'єкта відображається в його станах, і даний тип діаграм дозволяє відобразити це графічно. Для цього використовується два види діаграм: Statechart diagram (дмаграмма станів) і Activity diagram (діаграма активності)

Statechart diagram (діаграма станів)

Діаграма станів (Statechart) призначена для відображення станів об'єктів системи, які мають складну модель поведінки. Це одна з двох діаграм State Machine, доступ до якої здійснюється з одного пункту меню.

Activity diagram (діаграми активності)

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

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

Interaction diagram (діаграми взаємодії)

Цей тип діаграм включає в себе діаграми Sequence diagram (діаграми послідовностей дій) і Collaboration diagram (діаграми співробітництва). Ці діаграми дозволяють з різних точок зору розглянути взаємодія об'єктів в створюваній системі.

Sequence diagram (діаграми послідовностей дій)

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

Даний тип діаграм дозволяє відобразити послідовність передачі повідомлень між об'єктами.

Цей тип діаграми не акцентує увагу на конкретному взаємодії, головний акцент приділяється послідовності прийому / передачі повідомлень. Для того щоб окинути поглядом всі взаємозв'язки об'єктів, служить Collaboration diagram

Collaboration diagram (діаграми співробітництва)

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

Через те, що діаграми Sequence і Collaboration є різними поглядами на одні й ті ж процеси, Rational Rose дозволяє створювати з Sequence діаграми діаграму Collaboration і навпаки, а також проводить автоматичну синхронізацію цих діаграм.

Class diagram (діаграми класів)

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

Значки діаграми дозволяють відображати складну ієрархію систем, взаємозв'язку класів (Classes) і інтерфейсів (Interfaces). Даний тип діаграм протилежний за змістом діаграмі Collaboration, на якому відображаються об'єкти системи. Rational Rose дозволяє створювати класи за допомогою даного типу діаграм у різних нотациях. У нотації, запропонованої Г. Бучем, яка так і називається Booch, класи зображуються у вигляді чогось нечіткого, схожого на хмару. Таким чином Г. Буч намагається показати, що клас - це лише шаблон, за яким надалі буде створений конкретний об'єкт.

Component diagram (діаграми компонентів)

Цей тип діаграм призначений для розподілу класів і об'єктів по компонентах при фізичному проектуванні системи. Часто даний тип діаграм називають діаграмами модулів.

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

3.1 Розробка виду з погляду прецендентів

Вид з погляду прецендентів включає наступні типи діаграм:

> діаграмма прецедентів;

> діаграма діяльності;

діаграма станів.

Розглянемо на прикладі предметної області “Моделювання процесу роботи будівельної компанії”, кожну з діаграм розглянемо більш детально.

Діаграма прецендентів

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

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

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

>прецеденти,

>акторів,

>відносини залежності, узагальнення та асоціації, як і всі інші діаграми, вони можуть містити примітки та обмеження.

Іноді діаграми прецедентів поміщають у пакети, застосовувані для групування елементів моделі в більш великі блоки, в ряді випадків і екземпляри прецедентів, особливо якщо треба візуалізувати конкретну виконувану систему.

У даному випадку діаграма буде содержати наступні складові елементи:

Прецедент-специфікація послідовностей дій (варіанти послідовностей і помилкові послідовності) в уніфікована мова моделювання (UML), які може здійснювати система, підсистема або клас, взаємодіючи із зовнішніми акторами.

Актор - це роль об'єкта поза системою, який прямо взаємодіє з її частиною - конкретним елементом (елементом Use Case). Розрізняють акторів і користувачів. Користувач - це фізичний об'єкт, який використовує систему. Він може грати кілька ролей і тому може моделюватися кількома акторами. Справедливо і зворотне - актором можуть бути різні користувачі. Лемента Use Case (Прецедент) - опис послідовності дій (чи декількох послідовностей), виконуваних системою в інтересах окремого актора і виробляють видимий для актора результат. У моделі елемент Use Case застосовується для структурування предметів поведінки. Елемент Use Case реалізується кооперацією. Як показано на рис. 10.5, елемент Use Case зображується як еліпс, в який вписується його ім'я.

Можемо виділити такі прецеденти:

Прецедент	Короткий опис
Управління персоналом	Запускається Адміністратором, дозволяє керувати діями персоналу, повідомляти їм про в'їзд нового клієнта.
Початкове обслуговування клієнта	Запускається Адміністратором, дозволяє вносити та корегувати дані про заїзд, змінювати характеристику номерів. Включає в себе прецеденти «Управління інформацією про клієнта», який дозволяє корегувати та вносити нові дані про клієнта, «Оформлення замовлення послуг», що дозволяє оформлювати замовлення додаткових послуг на окремий рахунок клієнта.
Виконання послуг	Запускається актором Персонал готелю, що включає в себе акторів Покоївки та Робітники ресторану. Дозволяє персоналу виконувати необхідні та додаткові заказані клієнтом послуги.

Приведена нижче діаграма відображає взаємодію даних елементів між собою (рис. 3.1)



Рисунок 3.1-Діаграма прецедентів

Діаграма діяльності

Для моделювання процесу виконання операцій в UML використовуються так звані діаграми діяльності. Застосовувана в них графічна нотація багато в чому схожа на нотацію діаграми станів, оскільки на діаграмах діяльності також присутні позначення станів і переходів. Відмінність полягає в семантиці станів, які використовуються для подання не діяльностей, а дій, і у відсутності на переходах сигнатури подій. Кожен стан на діаграмі діяльності відповідає виконанню деякої елементарної операції, а перехід у наступний стан спрацьовує тільки при завершенні цієї, операції в попередньому стані. Графічно діаграма діяльності представляється у формі графа діяльності, вершинами якого є стани дії, а дугами - переходи від одного стану дії до іншого. Таким чином, діаграми діяльності можна вважати окремим випадком діаграм станів. Саме вони дозволяють реалізувати в UML особливості процедурного і синхронного управління, обумовленого завершенням внутрішніх діяльностей і дій. На діаграмі діяльності відображається логіка або послідовність переходу від однієї діяльності до іншої, при цьому увагу фіксується на результаті діяльності. Сам же результат може привести до зміни стану системи або повернення деякого значення. Створимо діаграму діяльності для предметної області «Готель». Розглянемо, що трапляється в готелі при прибутті клієнта. Усього в готелі три підрозділа - адміністрація, обслуговування номерів та ресторан. При прибутті клієнта та заселення його в номер адміністрація питає його про надання можливих додаткових послуг - наприклад, годування двічи (або тричі) разів у день за окрему плату - що йде на рахунок робітників ресторану. Послуга прибирання номерів включається в платню за проживання - тобто послуга прибирання в номері реалізується персоналом в любому випадку. Якщо клієнт згоден з наданням додаткових послуг за окрему плату, адміністратор повідомляє це робітникам ресторану, також одночасно він повідомляє робітникам готелю про прибуття нового клієнту. Робітники готелю повинні привести клієнта у номер та кожен день прибирати там, поки він не покине номер. Робітники ресторану повинні приносити йому їжу у відповідності до заказаної ним послуги, поки він не покине номер або дія послуги не закінчиться.

Приведена нижче діаграма відображає взаємодію даних елементів між собою (рис. 3.2 )



Рисунок 3.2- Діаграма діяльності

Діаграма станів

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

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

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

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

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

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

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

Поведінка автомата моделюється як послідовне переміщення по графу від вершини до вершини з урахуванням орієнтації пов'язують їх дуг.

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

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

Приведена нижче діаграма відображає взаємодію даних елементів між собою (рис. 3.3)



Рисунок 3.3- Діаграма станів

3.2 Розробка виду з погляду проектування

Вид з погляду прецендентів включає наступні типи діаграм:

> діаграмма послідовності;

> діаграма класів;

> діаграма кооперацій.

Розглянемо на прикладі предметної області “Моделювання процесу роботи будівельної компанії”, кожну з діаграм розглянемо більш детально.

Діаграма послідовності

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

>об'єкти-на діаграмі послідовності зображаються тільки ті об'єкти, які безпосередньо беруть участь у взаємодії. Ключовим моментом для діаграм послідовності є динаміка взаємодії об'єктів в часі. В UML діаграма послідовності має як би два виміри. Перше зліва направо у вигляді вертикальних ліній, кожна з яких зображає лінію життя окремого об'єкта, який бере участь у взаємодії. Крайнім зліва на діаграмі зображується об'єкт, який є ініціатором взаємодії. Правіше зображається інший об'єкт, який безпосередньо взаємодіє з першим. Таким чином, всі об'єкти на діаграмі послідовності утворюють деякий порядок, який визначається черговістю або ступенем активності об'єктів при взаємодії один з одним.

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

>лінія життя об'єкта-зображується пунктирною вертикальною лінією, асоційованою з єдиним об'єктом на діаграмі послідовності. Лінія життя служить для позначення періоду часу, протягом якого об'єкт існує в системі і, отже, може потенційно брати участь у всіх її взаємодіях. Якщо об'єкт існує в системі постійно, то і його лінія життя повинна тривати по всій площині діаграми послідовності від самої верхньої її частини до самої нижньої. Окремі об'єкти, виконавши свою роль в системі, можуть бути знищені, щоб звільнити займані ними ресурси. Для таких об'єктів лінія життя обривається в момент його знищення. Для позначення моменту знищення об'єкта в мові UML використовується спеціальний символ у формі латинської букви «X». Об'єкт обов'язково створюється зі своєю лінією життя і, можливо, з фокусом управління.

>фокус управління-процесі функціонування об'єктно-орієнтованих систем, одні об'єкти можуть перебувати в активному стані, безпосередньо виконуючи певні дії, або стані пасивного очікування повідомлень від інших об'єктів. Щоб явно виділити подібну активність об'єктів, у мові UML застосовується спеціальне поняття, що отримало назву фокуса управління (focus of control). Фокус управління зображується у формі витягнутого вузького прямокутника, верхня сторона якого означає початок отримання фокусу управління об'єкта (початок активності), а його нижня сторона - закінчення фокусу управління (закінчення активності). Прямокутник розташовується нижче позначення відповідного об'єкту і може замінювати його лінію життя, якщо на всьому її протязі він є активним. Періоди активності об'єкта можуть чергуватися з періодами його пасивності або очікування. У цьому випадку у такого об'єкта є декілька фокусів управління.

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

Головними елементами в діаграмі послідовності є об'єкти, які представлені у вигляді прямокутників: «Адміністратор», «Заїзди», «Клієнти», «Номери», «Платники» ; вертикальні лінії, які відображають життя об'єкта та повідомлення, які графічно представлені у вигляді стрілок.

Приведена нижче діаграма відображає взаємодію даних елементів між собою (рис. 3.4)



Рисунок 3.4-Діаграма послідовності

Діаграма класів

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

Клас - це основний будівельний блок ПС. Це поняття присутнє і в ГО мовами програмування, тобто між класами UML та програмними класами є відповідність, що є основою для автоматичної генерації програмних кодів або для виконання реінжинірингу. Кожен клас має назву, атрибути і операції. Клас на діаграмі показується у вигляді прямокутника, розділеного на 3 області. У верхній міститься назва класу, в середній - опис атрибутів (властивостей), у нижній - назви операцій - послуг, що надаються об'єктами цього класу.

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

Для кожного атрибута класу можна задати видимість (прозорість). Ця характеристика показує, чи доступний атрибут для інших класів. В UML визначено такі рівні видимості атрибутів:

>відкритий (публічне) - атрибут видно для будь-якого іншого класу (об'єкта);

>захищений (захищений) - атрибут видно для нащадків даного класу;

>закритий (приватні) - атрибут не видно зовнішніми класами (об'єктами) і може використовуватися лише об'єктом, його містить.

Клас містить оголошення операцій, що представляють собою визначення запитів, які повинні виконувати об'єкти даного класу. Кожна операція має сигнатуру, що містить ім'я операції, тип значення і список параметрів, який може бути порожнім. Реалізація операції у вигляді процедури - це метод, що належить класу. Для операцій, як і для атрибутів класу, визначено поняття "видимість". Закриті операції є внутрішніми для об'єктів класу і недоступні з інших об'єктів. Решта утворюють інтерфейсну частина класу і є засобом інтеграції класу в ПС.

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

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

При створенні діаграм класів часто користуються поняттям "стереотип". Надалі мова піде про стереотипи класів. Стереотип класу - це елемент розширення словника UML який позначає відмітні особливості у використанні класу. Стереотип має назву, яка задається у вигляді текстового рядка. При зображенні класу на діаграмі стереотип показується у верхній частині класу в подвійних кутових дужках. Є чотири стандартних стереотипу класів, для яких передбачені спеціальні графічні зображення.

Стереотип використовується для позначення класів-сутностей (класів даних), стреотіп описує прикордонні класи, які є посередниками між ПС і зовнішніми по відношенню до неї сутностями - акторами, що позначаються стереотипом <>. Нарешті, стереотип описує класи та об'єкти, які управляють взаємодіями. Застосування стереотипів дозволяє, зокрема, змінити вид діаграм класів.

Діаграма класів складається з наступних класів: «Номери», «Матеріально-технічне забезпечення», «Персонал», «Клієнти», «Заїзди», «Заробітна платня», «Послуги», «Платники».

Між класами установлюється асоціація ”один до багатьох”, ”багато до багатьох”. Кожен клас має атрибути.

Приведена нижче діаграма відображає взаємодію даних елементів між собою (рис. 3.5)

Рисунок 3.5-Діаграма класів

Діаграма кооперацій

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

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