21293

Методологія обєктно-орієнтованого аналізу і проектування ПЗ. Мова UML

Лекция

Информатика, кибернетика и программирование

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

Украинкский

2013-08-02

72.5 KB

30 чел.

Лекція 1. Методологія об'єктно-орієнтованого
аналізу і проектування ПЗ. Мова UML

Зіставлення і взаємозв'язок структурного та об'єктно-орієнтованого підходів

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

  Буч відзначив також ряд наступних переваг ООП:

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

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

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

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

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

Історія розвитку та введення в UML

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

  Більшість сучасних методів ООАП засновані на використанні мови UML. Уніфікована мова моделювання 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 знаходиться в процесі стандартизації, проведеному OMG (Object Management Group) - організацією зі стандартизації в області об'єктно-орієнтованих методів і технологій, в даний час прийнятий в якості стандартного мови моделювання. UML прийнятий на озброєння практично усіма найбільшими компаніями - виробниками ПЗ (Microsoft, Oracle, IBM, Hewlett-Packard, Sybase та ін.) Крім того, практично всі світові виробники CASE-засобів, крім IBM Rational Software, підтримують UML у своїх продуктах (Oracle Designer, Together Control Center (Borland), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler та ін.)

  Стандарт UML версії 1.1, прийнятий OMG в 1997 р., містить такий набір діаграм:

  •  Структурні (structural) моделі:
    •  діаграми класів (class diagrams) - для моделювання статичної структури класів системи та зв'язків між ними;
    •  діаграми компонентів (component diagrams) - для моделювання ієрархії компонентів (підсистем) системи;
    •  діаграми розміщення (deployment diagrams) - для моделювання фізичної архітектури системи.
  •  Моделі поведінки (behavioral):
    •  діаграми варіантів використання (use case diagrams) - для моделювання функціональних вимог до системи (у вигляді сценаріїв взаємодії користувачів із системою);
    •  діаграми взаємодії (interaction diagrams):
    •  діаграми послідовності (sequence diagrams) і кооперативні діаграми (collaboration diagrams) - для моделювання процесу обміну повідомленнями між об'єктами;
    •  діаграми станів (statechart diagrams) - для моделювання поведінки об'єктів системи при переході з одного стану в інший;
    •  діаграми діяльності (activity diagrams) - для моделювання поведінки системи в рамках різних варіантів використання, або потоків управління.

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

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

  Діаграма варіантів використання є найбільш загальним поданням функціональних вимог до системи. Для подальшого проектування системи потрібні більш конкретні деталі, які описуються в документі, званому «сценарієм варіанти використання» або «потоком подій» (flow of events). Сценарій докладно документує процес взаємодії дійової особи з системою, що реалізується в рамках варіанту використання. Основний потік подій описує нормальний хід подій (при відсутності помилок). Альтернативні потоки описують відхилення від нормального перебігу подій (помилкові ситуації) і їх обробку.

  Переваги моделі варіантів використання полягають в тому, що вона:

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

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

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

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

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

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

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

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

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

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

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

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

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

  UML має механізмами розширення, призначеними для того, щоб розробники могли адаптувати мову моделювання до своїх конкретних потреб, не змінюючи при цьому його метамодель. Наявність механізмів розширення принципово відрізняє UML від таких засобів моделювання, як IDEF0, IDEF1X, IDEF3, DFD та ERM. Перераховані мови моделювання можна визначити як сильно типізовані (за аналогією з мовами програмування), оскільки вони не допускають довільній інтерпретації семантики елементів моделей. UML, допускаючи таку інтерпретацію (в основному за рахунок стереотипів), є слабо типізовані мовою. До його механізмам розширення відносяться:

  •  стереотипи;
  •  тегованих (іменовані) значення;
  •  обмеження.

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

72042. ОБГРУНТУВАННЯ ПАРАМЕТРІВ І УДОСКОНАЛЕННЯ СИСТЕМИ ВІДСІЧЕННЯ КОНВЕРТЕРНОГО ШЛАКУ ЕЛЕМЕНТАМИ ПОПЛАВКОВОГО ТИПУ ПРИ ВИПУСКУ СТАЛІ 3.67 MB
  Мінімізація кількості кінцевого шлаку що потрапляє в розливний ківш під час випуску металу з кисневого конвертера є важливим технологічним завданням від успішного вирішення якого значною мірою залежать ефективність подальшої позапічної обробки сталі і виробничі витрати зумовлені...
72043. СТАТИСТИЧНИЙ АНАЛІЗ ПОВЕДІНКИ САМООРГАНІЗОВАНИХ СКЛАДНИХ СИСТЕМ 2.15 MB
  У фізиці можна виділити феромагнетики спінове скло двовимірну електронну плазму у турбулентному режимі системи з аномальною дифузією Леві гранульовані системи тверді тіла піддані йонному бомбардуванню гравітаційні системи сонячні нейтрино чорні діри елементарні частинки які зіштовхуються...
72044. МЕДИКАМЕНТОЗНИЙ ДИСБАКТЕРІОЗ У КОТІВ: ДІАГНОСТИКА ТА РОЗРОБКА ЗАСОБУ ДЛЯ ЛІКУВАННЯ 302.5 KB
  Кишкові дисбактеріози дрібних свійських тварин зокрема котів досить розповсюджені однак на цей час відсутні науково обґрунтовані дані щодо змін видового складу та кількісного співвідношення мікрофлори шлунковокишкового тракту при розвитку захворювання крім того при запровадженні...
72045. РОЗВИТОК НАУКОВИХ ОСНОВ ФОРМУВАННЯ СТРУКТУРИ ТА ВЛАСТИВОСТЕЙ ЗНОСОСТІЙКИХ НИЗЬКОХРОМИСТИХ ЧАВУНІВ ДЛЯ ДЕТАЛЕЙ ТЕХНОЛОГІЧНОГО ОБЛАДНАННЯ 377 KB
  Важливе місце в переробці сировинних і будівельних матеріалів належить операціям дроблення, подрібнювання та розмелу, що споживають більше половини всіх енергетичних і матеріальних витрат переробних підприємств у гірничо-металургійній, сировинній, будівельній і енергетичній галузях промисловості України.
72046. ДОІНДОЄВРОПЕЙСЬКИЙ СУБСТРАТ У ЛЕКСИЦІ СЛОВ’ЯНСЬКИХ, ГЕРМАНСЬКИХ І РОМАНСЬКИХ МОВ 195 KB
  Актуальність дисертаційної роботи продиктовано сучасною тенденцією компаративістики до вивчення мовних явищ у тісному зв’язку з історією та культурою народу загалом та необхідністю комплексного дослідження міжетнічних і міжкультурних контактів, на тлі яких зростає інтерес до етногенетичних процесів...
72047. ФОРМУВАННЯ ЛОГІСТИЧНОЇ МОДЕЛІ УПРАВЛІННЯ ДІЯЛЬНІСТЮ КОМУНАЛЬНИХ ФАРМАЦЕВТИЧНИХ ПІДПРИЄМСТВ В УМОВАХ МЕНЕДЖМЕНТУ ЯКОСТІ 920 KB
  Головною метою діяльності комунальних фармацевтичних підприємств КФП є виконання соціальної функції щодо максимально повного і ефективного забезпечення населення регіону доступними за ціною та якісними лікарськими засобами ЛЗ і виробами медичного призначення ВМП.
72048. ЕМБРІОНАЛЬНИЙ ГІСТОГЕНЕЗ НИРКИ У РАННІХ ЗАРОДКІВ ЛЮДИНИ 197 KB
  В тепершній час відсутня концепція механізмів регуляції розвитку людини оскільки більшість наведених у літературі даних грунтується на вивченні ембріогенезу експериментальних тварин або на культивуванні ембріональних клітин.
72049. СТРАТЕГІЧНИЙ АНАЛІЗ КОНКУРЕНТОСПРОМОЖНОСТІ ПІДПРИЄМСТВ 234.5 KB
  За відсутності комплексної методики аналізу конкурентоспроможності підприємства виникає низка важливих питань які потребують вирішення. Для досягнення належної конкурентоспроможності підприємства необхідні тривалий час і значні зусилля.
72050. СОЦІАЛЬНЕ ПРОЕКТУВАННЯ: ПРОБЛЕМА ВЗАЄМОЗВ’ЯЗКУ СУСПІЛЬНИХ ПОТРЕБ І ДЕРЖАВНИХ ІНТЕРЕСІВ 287 KB
  На підґрунті діалектичного підходу сутність соціального проектування розкривається як суперечливий процес відтворення рефлексивної єдності соціального суб’єкта та об’єктивної реальності. Згідно з цим реалізується принцип відповідності, за яким встановлюються логіко-гносеологічні засоби відновлення...