31

ЗМІСТ

ЗМІСТ 1

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

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

ЛАБОРАТОРНА РОБОТА №3 16

ЛАБОРАТОРНА РОБОТА №4 18

ЛАБОРАТОРНА РОБОТА №5 20

ЛАБОРАТОРНА РОБОТА №6 22

ЛАБОРАТОРНА РОБОТА №7 24

ЛАБОРАТОРНА РОБОТА №8 27

ЛАБОРАТОРНА РОБОТА №9 29

Лабораторна робота №1

Тема:

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

.Мета роботи

Отримати загальні уявлення про процес моделювання систем, про мову моделювання 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 визначав дванадцять типів діаграм, розділених на три групи:

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

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

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