Лекція 3. Моделі програмного забезпечення і їх роль у створенні систем. Unified Modelling Language

Одна з основних проблем при створенні великих і складних систем, зокрема ПЗ, - це проблема складності. Види складності: технічна складність і складність управління.

Технічна складність може бути викликана:

Ø структурною складністю (великою кількістю елементів і складними взаємозв'язками між ними);

Ø відсутністю повних аналогів, що обмежує можливість використання типових проектних рішень і прикладних систем;

Ø необхідністю інтеграції існуючих застосувань і застосувань, які розробляються заново;

Ø функціонуванням в неоднорідному середовищі на декількох апаратних платформах;

Ø високими вимогами до надійності і продуктивності.

Складність управління породжується наступними причинами:

Ø сильна дія зовнішнього середовища (політика, економічна ситуація, контракти, багато зацікавлених осіб, суперечливі вимоги);

Ø великий колектив розробників, багато різних проектів і продуктів;

Ø роз'єднаність і різнорідність окремих груп розробників за рівнем кваліфікації і традиціями використання інструментальних засобів;

Ø значна часова тривалість проекту.

Підхід до розв’язування цієї проблеми базується на принципі «розділяй і володарюй» (divide et impera). Складна програмна система повинна бути розділена на невеликі підсистеми, кожну з яких можна розробляти незалежно від інших. Декомпозиція є головним способом подолання складності розробки ПЗ. Принципи декомпозиції:

Ø слабка зв'язаність - low coupling (кількість зв'язків між окремими підсистемами повинна бути мінімальною);

Ø сильне зчеплення - high cohesion (зв'язність окремих частин усередині кожної підсистеми повинна бути максимальною).

При розбитті системи на підсистеми необхідно виконати наступні вимоги:

Ø кожна підсистема повинна інкапсулювати свій вміст (приховувати його від інших підсистем);

Ø кожна підсистема повинна мати чітко визначений інтерфейс з іншими підсистемами;

Ø взаємодії між підсистемами повинні укладатися в обмежені, стандартні рамки.

Дотримання цих правил збільшує зрозумілість і модифікованість створюваного ПЗ.

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

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

Ø сукупність структурних елементів системи і зв'язків між ними;

Ø поведінка елементів системи у процесі їх взаємодії;

Ø ієрархію підсистем, які об'єднують структурні елементи.

Архітектура ПЗ багатовимірна, оскільки різні фахівці працюють з її різними аспектами. Різні представлення архітектури служать різним цілям (модель «4+1»):

Ø представлення функціональних можливостей ПЗ (представлення варіантів використання);

Ø представлення логічної організації ПЗ (логічне представлення);

Ø представлення фізичної структури програмних компонент, які входять в склад ПЗ (представлення реалізації);

Ø представлення структури потоків управління і аспектів паралельної роботи ПЗ (представлення процесів);

Ø опис фізичного розміщення компонент ПЗ по вузлах обчислювальної системи (представлення розміщення).

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

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

Граді Буч:

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

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

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

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

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

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

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

У процесі створення ПЗ використовуються наступні види моделей:

Ø моделі діяльності організації (або моделі бізнес-процесів):

o моделі "AS-IS" ("як є"), які відображають існуюче положення;

o моделі "AS-TO-BE" ("як повинно бути"), які відображають уявлення про нові процеси і технології роботи організації;

Ø моделі ПЗ, яке проектується і які будуються на основі моделі "AS-TO-BE", уточнюються і деталізуються до потрібного рівня.

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

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

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

UML є спадкоємцем методів об'єктно-орієнтованого аналізу і проектування, які з'явилися в кінці 1980-х і початку 1990-х років. Створення UML почалося в кінці 1994 р., з об'єднання методів Booch і OMT (Object Modeling Technique) під егідою компанії Rational Software. До кінця 1995 р. Граді Буч і Джеймс Рамбо створили першу специфікацію Unified Method, версія 0.8. Тоді ж в 1995 р. до них приєднався творець методу OOSE (Object-oriented Software Engineering) Івар Якобсон. UML є уніфікацією методів Буча, Рамбо і Якобсона а також сумою передового досвіду з розробки ПЗ:

Розробка UML переслідувала наступні цілі:

Ø надати розробникам єдину мову візуального моделювання;

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

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

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

UML широко використовується в індустрії ПЗ. Практично всі світові виробники CASE-засобів підтримують UML у своїх продуктах. У 2004 році Object Management Group прийняла UML версії 2.0. Раніше у 1997 році OMG прийняла стандарт UML 1.1.

Кооперативна діаграма (діаграма комунікації)

Діаграма послідовності з блоками UML 2.x

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

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

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

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

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

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

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

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

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

Діаграми діяльності потрібно використовувати у наступних ситуаціях:

Ø при аналізі потоків подій у конкретному варіанті використання;

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

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

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

Ø вузол (node) - обчислювальний ресурс - процесор або інший пристрій (дискова пам'ять, контроллери різних пристроїв і так далі);

Ø з'єднання (connection) - канал взаємодії вузлів.

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

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

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

Ø стереотипи;

Ø теги (ключові слова);

Ø примітки;

Ø обмеження.

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

Стереотипи класів - це механізм, який дозволяє розділяти класи на категорії. Наприклад, основними стереотипами, використовуваними у процесі аналізу системи, є: Boundary (граничний клас), Entity (клас-сутність) і Control (управляючий клас).

Крім згаданих стереотипів, розробники ПЗ можуть створювати свої власні набори стереотипів, формуючи тим самим спеціалізовані підмножини UML (наприклад, для опису бізнес-процесів, Web-застосувань, баз даних і так далі). Такі підмножини (набори стереотипів) у стандарті мови UML носять назву профілів мови.

Теги (ключові слова) - спеціальні терміни, використовувані специфікації обмежень і властивостей, такі як disjoint, complete, incomplete і ін., можуть супроводжуватися вказівкою значення властивості, наприклад, author=вася або location=server.

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

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

Ø опис інваріантів класів і типів у моделі класів;

Ø опис передумов і постумов в операціях і методах;

Ø опис обмежуючих умов елементів моделі;

Ø навігація по структурі моделі;

Ø специфікація обмежень на операції.

Література до лекції 3

1. Соммервил И. Инженерия программного обеспечения. 6-е изд.: Пер. с англ. – М.: Вильямс, 2002.

2. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2006. – Главы 1, 2.

3. К. Ларман «Применение UML и шаблонов проектирования»

4. Фаулер М. UML. Основы. 3-е издание. Краткое руководство по стандартному языку объектного моделирования.: Пер. с англ. – СПб: Символ-Плюс, 2005.

5. Г. Буч, Дж. Рамбо, И. Якобсон «UML. Руководство пользователя»

6. Розенберг Д., Скотт К. «Применение объектно-ориентированного моделирования с использованием UML и анализ прецедентов»

7. Шмуллер Дж. «Освой самостоятельно UML за 24 часа»

8. Дж. Коналлен «Разработка WEB-приложений с использованием UML»

9. Мацяшек Л. Анализ и проектирование информационных систем с помощью UML 2.0. М.: ООО «И.Д. Вильямс», 2008. – 816 с.

10. Киммел П. UML. Основы визуального анализа и проектирования / Пол Киммел. – М.: НТ Пресс, 2008. – 272 с.

Дата добавления: 2014-01-07