Моделювання систем. Загальні уявлення про UML.

ЛАБОРАТОРНА РОБОТА №1

Тема:

. Мета роботи

Отримати загальні уявлення про процес моделювання систем, про мову моделювання UML та навчитися використовувати MS Visio як CASE-засобу.

Теоретичні відомості

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

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

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

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

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

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

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

Діаграми - лише засіб візуалізації моделі, і ці два поняття варто розрізняти. Лише набір діаграм становить модель системи й найбільше повно неї описує, але не одна діаграма, вирвана з контексту.

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

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

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

Уніфікована мова моделювання UML (Unified Modeling Language) – це спадкоємець того покоління методів ООАП, які з'явилися наприкінці 80-х і початку 90-х рр.

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

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

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

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

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

Офіційне створення UML почалося у жовтні 1994 року, коли Рамбо перейшов у компанію Rational Software, де працював Буч.

Версія 1.0 мови з'явилася в результаті спільних зусиль компаній Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments і Unisys. UML 1.0 виявилася виразною, потужною мовою, яку можна застосовувати для рішення великої кількості різноманітних завдань. У січні 1997 року вона була представлена Групі по керуванню об'єктами (Object Management Group, OMG) на конкурс по створенню стандартної мови моделювання.

У вересні версія була затверджена на засіданнях Групи по аналізу й проектуванню й Комітету з архітектурі OMG, a 14 листопада 1997 року прийнята як стандарт на загальних зборах всіх членів OMG.

Подальша робота з розвитку UML проводилася Групою по вдосконаленню (Revision Task Force, RTF) OMG під керівництвом Криса Кобрина. У червні 1998 року вийшла версія UML 1.2, а восени 1998 р. – UML 1.3.

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

Взагалі ж, в UML використається чотири види елементів нотації:

1) фігури,

2) лінії,

3) значки,

4) написи.

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

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

Взагалі ж варто сказати, що UML надає виняткову свободу - можна малювати що завгодно і як забажається, аби тільки можна було зрозуміти зміст створених діаграм..

Інструменти малювання. До таких пакетів можна віднести:

· IBM Rational Rose;

· Borland Together;

· Gentleware Poseidon;

· Microsoft Visio;

· Telelogic TAU G2.

Види діаграм UML. UML 1.5 визначав дванадцять типів діаграм, розділених на три групи:

· чотири типи діаграм представляють статичну структуру додатка;

· п'ять представляють поведінкові аспекти системи;

· три представляють фізичні аспекти функціонування системи (діаграми реалізації).

Хід виконання роботи

Дати відповіді на питання.

Як розшифровується абревіатура UML?
Яка версія UML є поточної?
Хто були авторами UML?
Чим НЕ є UML?
Які програмні засоби, що підтримують UML, ви знаєте?
Чи використаються в UML "тривимірні" фігури?

ЛАБОРАТОРНА РОБОТА №2 (частина перша)

Тема

Діаграма прецедентів (use case diagram)

Мета роботи

Отримати уявлення про діаграму прецедентів

Теоретичні відомості

Будь-які (у тому числі й програмні) системи проектуються з обліком того, що в процесі своєї роботи вони будуть використатися людьми й/або взаємодіяти з іншими системами. Сутності, з якими взаємодіє система в процесі своєї роботи, називаються е кторами, причому кожний ектор очікує, що система буде поводитися строго певним, передбачуваним чином. UML Zicom Mentor:

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

Графічно ектор зображується або "чоловічком", подібним тим, які ми малювали в дитинстві, зображуючи членів своєї родини, або символом класу з відповідним стереотипом, як показано на рис.2.1:

Рис 2.1. Ектор

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

Прецедент (use-case) - опис окремого аспекту поводження системи з погляду користувача (Буч).

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

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

Рис.2.2. Прецендент

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

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

Підводячи підсумки, можна виділити такі мети створення діаграм прецедентів:

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

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

· розробка концептуальної моделі системи для її наступної деталізації;

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

Розглянемо діаграму прецедентів (рис 2.3.)

Крім зазначених у практичній роботі №2 елементів, у цій діаграмі використовуються елементи, які дозволяють:

1) визначити візуально межі системи;

2) узагальнити об’єкти;

3) додати сценарії для прецеденту за допомогою коментарю;

4) зв’язати один прецедент з іншими, які є складовими частинами цього прецеденту (включення);

5) зв’язати прецедент з іншим (розширення), вказуючи на те, що цей прецедент є частиною іншого.

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

Прецедент	Ектор

Хід виконання роботи

1. Заповніть вище наведену таблицю.

2. Розробіть діаграму прецедентів для визначення моделі системи «Студент – Викладач».

3. Розробіть для своєї діаграми таблицю

Рис.2.3. Діаграма прецедентів

Лабораторна 2 (частина друга)

На рис.2.4 зображена діаграма прецедентів використання для системи управління теплицею.

Рис.2.4. Діаграма прецедентів використання

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

Розглянемо прецедент використання «Обслуговування резервуарів».