Лекція 6. Аналіз програмного забезпечення

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

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

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

· визначення структури кожного архітектурного уявлення;

· здійснення архітектурного аналізу.

Обов'язки розробника:

· аналіз варіантів використання (їх реалізація);

· визначення обов'язків, поведінки, властивостей класів і зв'язків між класами;

· аналіз одного або декількох пакетів або підсистем.

Розробник БД відповідає за модель даних (схему БД).

Розробник призначеного для користувача інтерфейсу (UI) створює екранні форми, навігаційні карти, здійснює прототіпірованіє UI.

Рецензент оцінює рішення, прийняті в ході процесу і створені робочі продукти (документи).

Об'єктно-орієнтований аналіз включає два види діяльності:

· архітектурний аналіз;

· аналіз варіантів використання.

Архітектурний аналіз виконується архітектором системи і включає:

· затвердження загальних стандартів (угод) моделювання і документування системи;

· попереднє виявлення архітектурних механізмів (механізмів аналізу);

· формування набору основних абстракцій предметної області (класів аналізу);

· формування початкового представлення архітектурних рівнів.

Угоди моделювання визначають:

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

· правила їх застосування;

· угоди з іменування елементів моделі;

· організацію моделі (пакети).

Угоди фіксуються у документі «Керівні вказівки з проектування» (Design Guidelines). Приклад угод:

1) Імена варіантів використання повинні бути короткими дієслівними фразами.

2) Для кожного варіанту використання повинен бути створений пакет Use-case Realization, який включає:

a. принаймні, одну реалізацію варіанту використання;

b. діаграму “ View Of Participating Classes” (VOPC)

3) Імена класів повинні бути іменниками, які відповідають, по можливості, поняттям предметної області.

4) Імена класів повинні починатися із великої букви.

5) Імена атрибутів і операцій повинні починатися з малої букви.

6) Складені імена повинні бути суцільними, без підкреслень, кожне окреме слово повинне починатися із великої букви.

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

· Механізми аналізу: забезпечують взаємодію класів і компонентів предметної області, без деталей реалізації.

· Проектні механізми: враховують деякі деталі середовища реалізації, без прив'язки до конкретного середовища (наприклад, вибір між РСУБД і ООСУБД).

· Механізми реалізації: залежать від конкретної технології, мови програмування, постачальника (Oracle, Sun або Microsoft) і так далі

Приклади механізмів аналізу:

· Стійкість (persistency): елементи моделі, які повинні зберігати свій стан протягом тривалого часу повинні бути визначені як стійкі (для кожного стійкого елемента визначаються його розмір і кількість об'єктів, які зберігаються, терміни зберігання, механізми і частотні характеристики доступу).

· Інтерфейс з успадкованими системами (legacy interface) - до цього механізму відносять всі елементи моделі, відповідальні за інтерфейс з успадкованою системою.

· Безпека (рівні, правила, привілеї) - елементи, які забезпечують контроль доступу до системи.

· Розподіл - елементи, які повинні бути розподілені по вузлах мережі.

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

Способи пошуку основних абстракцій:

· Пошук абстракцій за списком категорій:

o фізичні або матеріальні об'єкти;

o процеси (транзакції) і події;

o ролі людей, організації;

o абстрактні поняття.

· Визначення абстракцій з текстових описів - виділення іменників з описів (наприклад, варіантів використання) і їх вибір як «кандидатів» на роль абстракцій

Наступним етапом є формування початкового представлення архітектурних рівнів. Архітектурні рівні утворюють ієрархію рівнів представлення будь-якої великої системи. Майже у будь-якій системі можна виділити наступні рівні:

· прикладний, містить набір компонентів, які реалізовують основну функціональність системи;

· бізнес-рівень, який включає набір компонентів, специфічних для конкретної предметної області;

· проміжний (middleware), куди входять незалежні вд платформи сервіси;

· системний, містить компоненти обчислювальної і мережевої інфраструктури.

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

· Рівні (Layers) - спосіб декомпозиції застосування на набір шарів, які відповідають різним рівням абстракції.

· Модель-представлення-управління (Model-view-controller, M-V-C) - розділення застосування на три частини: дані і бізнес-правила; представлення для користувача; обробку даних.

· Канали і фільтри (Pipes and filters) - шаблон архітектури системи для потокової обробки даних.

Layers:

Прикладний рівень - реалізація функціональності варіантів використання.

Бізнес-рівень - набір компонентів, специфічних для конкретної предметної області.

Middleware - незалежні від платформи сервіси (GUI, ORB.)

System software - ПЗ для обчислювальної і мережевої інфраструктури (ОС, мережеві протоколи і ін.)

Зразок «Канали і фільтри» вирішує наступну проблему: Потрібно забезпечити перетворення безперервних потоків даних. При цьому перетворення інкрементні і наступне може бути почате до закінчення попереднього. Є, можливо, декілька входів і декілька виходів. Надалі можливе додавання додаткових перетворень.

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

Зразок «Model-view-controller» родом з мови Smalltalk.

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

Рішення: виділити набір компонентів 3-х типів: компонентів зберігання даних, компонентів представлення для користувачів, і компонентів обробки (які сприймають команди, перетворюють дані і оновлюють представлення).

Об'єкт Controller приймає події, які впливають на стан моделі, і обробляє їх, викликаючи методи класу Model для зміни даних моделі. Model після будь-якої зміни своїх даних оповіщає всі об'єкти View (їх може бути декілька) і Controller, посилаючи повідомлення update. Отримавши update об'єкти запрошують оновлені дані.

Мал. Взаємодія частин системи, яка диктується зразком MVC.

Аналіз варіантів використання виконується проектувальниками і включає:

· ідентифікацію класів, які беруть участь в реалізації потоків подій (так званих, класів аналізу);

· визначення обов'язків класів;

· визначення атрибутів і асоціацій класів;

· уніфікацію класів аналізу.

Кроки аналізу варіантів використання:

1. Уточнення і доповнення описів варіантів використання.

2. Для кожної реалізації варіанту використання:

а. Виявлення класів, які беруть участь у реалізації потоків подій варіанту використання.

b. Розподіл поведінки, яка реалізовується варіантом використання, між класами (обов'язки класів).

3. Для кожного виявленого класу аналізу:

а. Визначення обов'язків класу.

b. Визначення атрибутів і асоціацій.

с. Кваліфікація механізмів аналізу.

4. Уніфікація класів аналізу.

Класи аналізу відображають функціональні вимоги до системи і моделюють об'єкти предметної області. Сукупність класів аналізу є початковою концептуальною моделлю системи. У потоках подій варіанту використання виявляються класи трьох типів:

· граничні класи, які є посередниками при взаємодії із зовнішніми об'єктами;

· класи-сутності, які є основними абстракціями (поняттями), розроблюваної системи;

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

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

· інтерфейс користувача (обмін інформацією з користувачем, без деталей UI - кнопок, списків, вікон);

· системний інтерфейс і апаратний інтерфейс (використовувані протоколи, без деталей їх реалізації).

Способи виділення класів-сутностей:

· «Переведення» бізнес-сутностей з бізнес-моделі у класи-сутності.

· Аналіз глосарію (деякі терміни є іменами шуканих класів-сутностей).

· Аналіз описів варіантів використання:

о Виділіть іменники у потоці подій варіанту використання.

о Виключіть дублікати.

о Виключіть невизначеності.

о Виключіть дійових осіб.

о Виключіть деталі реалізації.

о Виключіть атрибути (знадобляться пізніше).

о Виключіть операції.

У результаті залишаються імена класів-сутностей.

Правило виділення управляючих класів: для кожного варіанту використання створюється відповідальний за його реалізацію клас управління.

Всі створені при аналізі даного варіанту використання класи аналізу поміщаються на діаграму VOPC (View Of Participating Classes).

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

· Знання:

о наявність інформації про дані або обчислювані величини;

о наявність інформації про зв'язані об'єкти.

· Дія:

о виконання деяких дій самим об'єктом;

о ініціація дій інших об'єктів;

о координація дій інших об'єктів.

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

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

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

При побудові діаграм взаємодії виникають проблеми правильного розподілу обов'язків між класами. Для їх вирішення існує ряд зразків (GRASP - General Responsibility Assigment Software Patterns), запропонованих Крегом Ларманом: Information Expert, Creator, Low Coupling, High Cohesion.

Зразок “Information Expert”.

Проблема: Потрібно визначити найбільш загальний принцип розподілу обов'язків між класами.

Рішення: Потрібно призначити обов'язок інформаційному експертові - класу, у якого є інформація, потрібна для виконання обов'язку. Приклад:

При виконанні підлеглого потоку подій "Відновити графік" варіанту використання "Зареєструватися на курси" студент-користувач повинен отримати доступ до свого графіка перш, ніж змінити його. Згідно зразка " Information Expert ", потрібно визначити, об'єкт якого класу містить інформацію, необхідну для доступу до графіка. На цю роль інформаційного експерта, очевидно, претендує об'єкт класу-сутності Student, оскільки графік належить саме йому. Тому повідомлення 3 "get schedule(forSemester)" повинно бути напрямлено від контроллера об'єкта класу Student. Після того, як студент отримає графік і внесе до нього необхідні зміни, вони повинні бути зафіксовані в об'єкті Schedule. У даному випадку вже сам об'єкті Schedule гратиме роль інформаційного експерта, оскільки він безпосередньо доступний контроллеру, і повідомлення 10 "Update with new selections" буде направлене саме йому.

Наслідки:

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

У деяких ситуаціях застосування зразка Information Expert небажано.

Зразок "Creator".

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

Рішення: Потрібно призначити класу В обов'язок створювати екземпляри класу А, якщо виконується одна з наступних умов:

· клас В агрегує, містить або активно використовує об'єкти класу А;

· клас B володіє даними ініціалізації, які передаватимуться об'єктам класу А при їх створенні (тобто клас В є інформаційним експертом).

· Клас В при цьому визначається як творець (creator) об'єктів класу А.

Якщо декілька класів задовольняють цим умовам, то краще використовувати як творця клас, агрегуючий або такий, що містить клас А.

Приклад: При виконанні підлеглого потоку подій "Створити графік" варіанту використання "Зареєструватися на курси" необхідно вирішити, хто повинен відповідати за створення нового графіка у системі. На мал. показано два можливі варіанти рішення цієї задачі.

Згідно зразка " Creator ", якнайкращим рішенням є варіант справа (новий об'єкт класу Schedule створюється класом Student, а не RegistrationController, оскільки саме Student задовольняє першій з перерахованих вище умов).

Наслідки: Зразок " Creator " визначає спосіб розподілу обов'язків, пов'язаний з процесом створення об'єктів. У об'єктно-орієнтованих системах це завдання є найбільш поширеним. Основним призначенням зразка Creator є знаходження об'єкта-творця, який при виникненні будь-якої події повинен бути пов'язаний зі всіма створеними ним об'єктами. При такому підході забезпечується низький ступінь зв'язаності об'єктів.

У деяких випадках як творець вибирається клас, який містить дані ініціалізації, які передаються об'єкту під час його створення. Насправді це приклад використання зразка Information Expert.

Зразок "Low Coupling".

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

Рішення: Слід розподілити обов'язки так, щоб забезпечити слабку зв'язаність. Зв'язаність (coupling) - це міра, яка визначає наскільки жорстко один елемент пов'язаний з іншими елементами, або якою кількістю даних про інші елементи він володіє. Елемент із слабкою зв'язаністю залежить від невеликого числа інших елементів. Клас з сильною зв'язаністю залежить багатьох інших класів. Наявність таких класів небажана, оскільки вона приводить до виникнення наступних проблем:

· Зміни у зв'язаних класах приводять до локальних змін у даному класі.

· Утруднюється розуміння кожного класу окремо.

· Ускладнюється повторне використання, оскільки для цього потрібний додатковий аналіз класів, з якими пов'язаний даний клас.

Приклад: Розглянемо підлеглий потік подій "Створити графік" варіанту використання "Зареєструватися на курси" (попередній малюнок). Згідно зразка " Low Coupling ", якнайкращим рішенням є варіант справа, оскільки при цьому у класі RegistrationController буде на один зв'язок менше (тобто, буде забезпечена слабкіша зв'язаність).

Наслдіки: Зразок Low Coupling підтримує незалежність класів, що, у свою чергу, підвищує можливості повторного використання і забезпечує вищу ефективність застосування. Його не можна розглядати ізольовано від інших зразків, таких як Information Expert і High Cohesion. Він також забезпечує виконання одного з основних принципів проектування, вживаних при розподілі обов'язків.

Зразок "High Cohesion".

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

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

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

Приклад: Використовуємо той же приклад, що і для попереднього зразка. Згідно зразка " High Cohesion ", якнайкращим рішенням також є варіант справа, оскільки при цьому клас RegistrationController делегує обов'язок створення нового об'єкту класу Shedule класу Student, і у самого класу RegistrationController буде на один обов'язок менше (тобто, його зчеплення буде сильніше).

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

Набір обов'язків класів, отриманий у результаті їх розподілу, повинен бути проаналізований на предмет виявлення і усунення наступних проблем:

· дублювання однакових обов'язків у різних класах;

· суперечливих обов'язків у рамках класу;

· класів з одним обов'язком або взагалі без обов'язків;

· класів, які взаємодіють з великою кількістю інших класів.

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

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

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

Уніфікація класів аналізу полягає у зміні моделі аналізу так, щоб дотримувалося виконання наступних умов:

· ім'я і опис кожного класу аналізу повинні відображати суть його ролі в системі;

· класи з однаковою поведінкою, або які представляють одне і те ж явище, повинні об'єднуватися;

· класи-сутності з однаковими атрибутами повинні об'єднуватися (навіть якщо їх поведінка відрізняється).

За результатами уніфікації класів повинні бути модифіковані описи варіантів використання.

Кваліфікація механізмів аналізу полягає в тому, що:

· Складається список всіх механізмів аналізу.

· Класи аналізу ставляться у відповідність механізмам аналізу.

· Визначаються характеристики механізмів аналізу.

Роль механізмів аналізу:

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

· Є набором типових рішень, або зразків (patterns), прийнятих як стандарт даного проекту.

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

Так, маючи справу із стійкими класами, досить вказати для них механізм «persistencу», не замислюючись як саме буде реалізовано збереження їх екземплярів у базі даних.

Приклад:

У описи класів зіставлених з архітектурними механізмами додаються додаткові характеристики, наприклад:

Характеристики класу Schedule:

· Об'єм: до 2000 графіків.

· Частота доступу:

о Створення: 500 в день.

о Читання: 2,000 звернень в годині

о Оновлення: 1,000 в день.

о Видалення: 50 в день.

Після закінчення модель аналізу повинна бути піддана перевірці:

1. Чи всі класи обгрунтовані належним чином?

2. Чи відображає ім'я кожного класу його роль?

3. Чи представляє клас єдину, чітко визначену абстракцію?

4. Чи є всі атрибути і обов'язки класу функціонально зв'язаними?

5. Чи відображають класи всю функціональність варіантів використання, відображену в основних, підлеглих і альтернативних потоках подій?

6. Чи однозначно розподілена поведінка за класами?

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

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.

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

3. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Глава 8-9.

4. Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007. Лекция 4.

5. Ларман Крэг. Применение UML 2.0 и шаблонов проектирования. 3-е изд. – М.: Вильямс, 2007.

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