21293

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

Лекция

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

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

Украинкский

2013-08-02

72.5 KB

28 чел.

Лекція 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.


 

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

48974. Інноваційні технології приготування страв з морського гребінця 551 KB
  Виробництво харчової продукції КУРСОВА РОБОТА з дисципліни: Технологія виробництва кулінарної продукції Тема: Інноваційні технології приготування страв з морського гребінця Керівник: Г. Значення страв з морського гребінця у харчуванні людини. Класифікація асортимент страв з морського гребінця 1. М'ясо морського гребінця легко засвоюється в організмі.
48975. Контурно-графічний аналіз результатів двохфакторного експерименту 667.5 KB
  Тернопільський національний технічний університет імені Івана Пулюя До постановки наукової проблеми про особливий статус медіакомунікацій масового спілкування в системі соціальних комунікацій Постановка наукової проблеми. До них відносять різновиди такого медіаспілкування яке по природі своїй є масовим що дає право називати медіа як масмедіа. Індивідуальна особистісна комунікація та масова комунікація це ті два основні види спілкування які природно супроводжують людину в усіх її особистісних та суспільних виявах....
48978. Автоматизація процесу сушіння деревини 270 KB
  Сушіння матеріалів є енергоємким процесом звязаним зі значною витратою палива пару а також електроенергії а отже використання високоточної автоматики дозволить значно скоротити термін сушіння та знизити енергетичні затрати. Також поширеним є сушіння круглих лісоматеріалів деталі опор ліній електропередачі зв'язки будівельні деталі. На даний час проблема автоматизації сушіння деревини вирішувалась шляхом використання застарілих як морально так і в фізичному плані приладів.
48979. Проектування бази даних готельного комплексу 334 KB
  Тема роботи: Проектування бази даних готельного комплексу Необхідно: спроектувати й реалізувати реляційну базу даних для централізованого зберігання інформації з метою полегшення і систематизації даних замовлень клієнтів. Моделювання реляційної бази даних.
48980. Методи прогнозування основних параметрів діяльності організації та їх ефективного застосування на прикладі ГК «Хлібодар» 279.5 KB
  Центральні поняття дослідження прогнозування основних параметрів діяльності організації. Сучасні наукові підходи до розуміння прогнозування основних Параметрів діяльності організації ПРОГНОЗУВАННЯ ОСНОВНИХ ПАРАМЕТРІВ ДІЯЛЬНОСТІ ОРГАНІЗАЦІЇ В СИСТЕМІ МЕНЕДЖМЕНТУ СУЧАСНОГО ПІДПРИЄМСТВА. Прогнозування в системі стратегічного менеджменту підприємства.
48982. Економічна ефективність виробництва ріпаку і шляхи її підвищення 320.5 KB
  Романенка Курсова робота Економічна ефективність виробництва ріпаку і шляхи її підвищення Студент відділення Економіка підприємства Наукові основи підвищення економічної ефективності виробництва ріпаку. Показники економічної ефективності виробництва ріпаку та методика їх визначення. Рівень виробництва ріпаку та його економічна ефективність.