21293

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

Лекция

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

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

Украинкский

2013-08-02

72.5 KB

25 чел.

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


 

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

12993. Авіаційні геоінформаційні комплекси 357 KB
  РОБОЧА НАВЧАЛЬНА ПРОГРАМА навчальної дисципліни Авіаційні геоінформаційні комплекси ВСТУП Метою навчальної дисципліни є вивчення теоретичних основ методів та засобів побудови авіаційних геоінформаційних комплексів. Головною задачею дисципліни Авіацій
12994. Вступ до предмету Інформатика 305.5 KB
  Лекція №1 Вступ до предмету Інформатика План 1. Вступ. Про цифрове проектування. 2. Відношення між аналоговим і цифровим. 3. Роль програмування в проектуванні цифрових пристроїв. 1. Вступ. Про цифрове проектування. В настоящий момент ...
12995. Представлення чисел в цифрових системах 217.5 KB
  Лекція №2. Представлення чисел в цифрових системах . План 1. Позиційна система числення. 2. Восьмирічні та шістнадцятирічні числа. 3. Переведення чисел з однієї системи числення в іншу. Цифровые системы строятся на основе схем в которых происх...
12996. Простейшие узлы вычислительной техники 400.5 KB
  Лекция №3 Тема Простейшие узлы вычислительной техники ЛОГИЧЕСКИЕ ФУНКЦИИ. Понятие о логической функции и логическом устройстве. Диоднорезисторные схемы. ТРИГГЕРЫ. Классификация триггеров. Асинхронные триггеры. Син
12997. СЧЕТЧИКИ. Суммирующие двоичные счетчики 138.5 KB
  Лекція № 4 Тема СЧЕТЧИКИ 1. СЧЕТЧИКИ. Общие сведения. 2. Суммирующие двоичные счетчики. 3. Вычитающий и реверсивный счетчики. 1.СЧЕТЧИКИ. Общие сведения. Счетчик цифровое устройство осуществляющее счет числа появлений на входе определенного логического уро...
12998. Шифратори, дешифратори 2.04 MB
  Тема: Шифратори дешифратори. 1. Шифратори 2. Дешифраторы 3. Линейный дешифратор. 4. Прямоугольный дешифратор. 5. АЦП и ЦАП. Принцип аналогоцифрового преобразования информации. 6. Дискретизация непрерывных сигналов. 7. Цифроаналоговые преобразователи. 7.1Схема ЦА
12999. Сумматоры Одноразрядный двоичный сумматор. 151.5 KB
  СУММАТОРЫ Одноразрядный двоичный сумматор. Из рассмотренного принципа сложения многоразрядных двоичных чисел следует что в каждом из разрядов производятся однотипные действий: определяется цифра суммы путем сложения по модулю 2 цифр слагаемых и поступающего в...
13000. Оперативные запоминающие устройства - ОЗУ(RAM). Постоянные запоминающие устройства (ПЗУ) 1.23 MB
  Лекция №7 Оперативные запоминающие устройства ОЗУRAM. Постоянные запоминающие устройства ПЗУ В радиоаппаратуре часто требуется хранение временной информации значение которой не важно при включении устройства. Такую память можно было бы построить на микросхе...
13001. Комбинированный программно-аппаратный метод представления эволюций сложных пространственных перемещений символов объектов 237 KB
  Лекция №8 Комбинированный программноаппаратный метод представления эволюций сложных пространственных перемещений символов объектов Ужесточение требований отображения множества разнотипных движущихся сложных символов объектов часто представленных матрицами 32