Тема: Метрики об’єктно-орієнтованих систем

​

1

Лекція 4

Мета створення метрик

​

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

​

• покращити якість продукту;
• оцінити ефективність процесу конструювання;
• покращити якість роботи на етапі проектування.

Характеристики об’єктно-орієнтованих систем

​

• локалізація;
• інкапсуляція;
• інформаційну закритість;
• наслідування;
• способи абстрагування об’єктів.

​

Ці характеристики мають максимальний вплив на об’єктно- орієнтовані метрики.

Метрики зв’язаності по даних

Загальні відомості

Л.Отт і Б.Мехра розробили модель секціонування класів. Секціонування основане на екземплярних змінних класу. Для кожного методу класу отримують ряд секцій, а потім виконують об'єднання всіх секцій класу. Вимір зв'язаності оснований на кількості лексем даних, які з'являються в кількох секціях і “зклеюють” секції в модуль. Під лексемами даних розуміють визначення констант і змінних або посилання на константи і змінні.

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

Метрики зв’язаності по даних

Ще одне базове поняття методики — секціонована абстракція. Секціонована абстракція — це об'єднання всіх секцій даних методу. Наприклад, секціонована абстракція методу SumAndProduct має вигляд:

​

​

Секціонованою абстракцією класу (Class Slice Abstraction) CSA(C) називають об’єднання секцій всіх екземплярних змінних класу. Повний набір секцій складають шляхом обробки всіх методів класу.

Склеєними лексемами називають ті лексеми даних, які є елементами більш чим однієї секції даних.

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

​

​

Метрики зв’язаності по даних

Для визначення відношень між секціями даних можна показати профіль секцій даних в методі.

Для визначення відношень між секціями даних можна показати профіль секцій даних в методі.

​

Метрики зв’язаності по даних

Профіль секцій даних для метода SumAndProduct

​

​

Метрики зв’язаності по даних

Метрики Абреу

Основними цілями метрик Абреу є:

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

​

​

Метрики Абреу

​

​

• фактор закритості методу (МНF)
• фактор закритості властивості (AHF)
• фактор наслідування методу (MIF)
• фактор наслідування властивості (AIF)
• фактор поліморфізму (POF)
• фактор зчеплення (СОF)

Метрики Абреу

1. Фактор закритості методу (МНF)

​

​

​

​

Mv(Ci) - кількість видимих методів в класі Ci (інтерфейс класу),

Mh(Ci) - кількість прихованих методів в класі Ci (реалізація класу),

Md(Ci) – загальна кількість методів в класі Ci (унаслідовані методи не враховуються),

Md(Ci) = Mv(Ci) + Mh(Ci),

TC – кількість класів в системі.

Із збільшенням значення метрики зменшується щільність дефектів в системі і витрати на їх усунення.

Метрики Абреу

2. Фактор закритості властивості (AHF)

​

​

​

Аv (Сi) — кількість видимих властивостей в класі Сi (інтерфейс класу);

Ah(Ci) — кількість прихованих властивостей в класі Сi (реалізація класу);

Ad(Ci)=Аv(Сi)+Ah(Ci) – загальна кількість властивостей, визначених в класі Сi (унаслідовані властивості не враховуються).

В ідеальному випадку всі властивості повинні бути приховані і доступні тільки для методів, які відповідного класу (AHF = 100%).

​

Метрики Абреу

3. Фактор наслідування методу (MIF)

​

​

​

Mi(Ci) – кількість унаслідованих і не перевизначених методів в класі Ci,

Mo(Ci) - кількість унаслідованих і перевизначених методів в класі Ci,

Mn(Ci) - кількість нових (не унаслідованих і не перевизначених) методів в класі Ci,

Md(Ci) - кількість методов, визначених в класі Ci,

Md(Ci) = Mn(Ci) + Mo(Ci),

Ma(Ci) – загальна кількість методів, доступних в класі Ci,

Ma(Ci) = Md(Ci) + Mi(Ci),

TC - кількість класів в системі.

Метрики Абреу

4. Фактор наслідування властивості (AIF)

​

​

​

Ai(Ci) – кількість унаслідованих і не перевизначених властивостей в класі Ci,

Ao(Ci) - кількість унаслідованих і перевизначених властивостей в класі Ci,

An(Ci) - кількість нових (не унаслідованих і не перевизначених) властивостей в класі Ci,

Ad(Ci) - кількість властивостей, визначених в класі Ci,

Ad(Ci) = An(Ci) + Ao(Ci),

Aa(Ci) - общее кількість властивостей, доступних в класі Ci,

Aa(Ci) = Ad(Ci) + Ai(Ci),

TC - кількість класів в системі.

​

Метрики Абреу

5. Фактор поліморфізму (POF)

​

​

​

​

​

Mo(Ci) - кількість унаслідованих і перевизначених методів в класі Ci,

Mn(Ci) - кількість нових (не унаслідованих і не перевизначених) методов в класі Ci,

DC(Ci) - кількість нащадків класу Ci.

​

​

​

​

​

Метрики Абреу

6. Фактор зчеплення (СОF)

​

​

​

​

is_client(Ci, Cj) – приймає значення 1, якщо клас Ci містить хоча б одне не унаслідоване посилання на властивість або метод класу Cj, інакше – значення 0.

TC – кількість класів в системі.

Знаменник відповідає максимально можливій кількості зчеплень.

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

Оцінка проектів на основі варіантів використання

(Use Case Points)

​

1

Use Case Points

Що таке UCP?

• UCP (Use Case Points) – це ;
• В основі UCP лежить методика Function points (оцінка на основі функціональних точок системи), але вона значно спрощена для використання не експертами Function points;
• На відміну від Function points, UCP враховує нефункціональні вимоги, організаційні ризики, компетенцію при оцінці та інші крітерії.

Що таке UCP?

• UCP (Use Case Points) – це вимір того, скільки зусиль потрібно для написання програмного забезпечення.
• Цей метод заснований на вивченні близько 200 проектів із середнім розміром 5 людино-років. Був знайдений спосіб використання оцінки, щоб бути в межах 10% від фактичних результатів більше 95% проектів. Цей метод з тих пір був включений в методологію RUP (методологія розробки програмного забезпечення, створена компанією Rational Software.)

Етапи оцінки

Оцінка акторів

Незкоригована оцінка варіантів використання

Оцінка технічних факторів

Оцінка зовнішніх факторів

Остаточний підрахунок

Оцінка акторів

Здійснюється оцінка складності інтерфейсів системи.

Всі діючі особи системи діляться на три типи: прості, середні і складні.

Простий – представляє зовнішню систему з чітко визначеним програмним інтерфейсом.

Середній – представляє або зовнішню систему, яка взаємодіє з даною системой через протокол на зразок ТСР/IР, або особистість, яка користується текстовим інтерфейсом (наприклад, алфавітно-цифровим терміналом).

Складний представляє собою особистість, яка використовує графічний інтерфейс користувача.

Оцінка акторів

Незкоригована оцінка �варіантів використання

Здійснюється оцінка масштабу системи.

Кожний варіант викорис-тання рангується в залежності від кількості транзакцій.

Альтернатива підрахунку за допомогою:

1. Класів
2. Об'єктів в базі даних .

​

​

​

​

​

Підрахунок показників

Оцінка технічних факторів

Оцінка технічних факторів

Показники технічної складності

Оцінка технічних факторів

Показники технічної складності

Оцінка зовнішніх факторів

Дає нам коефіцієнт для організаційних ризиків при розробці.

Показники рівня кваліфікації розробників

​

Оцінка зовнішніх факторів

Оцінка трудоємності проекту

Оцінка трудоємності проекту

Потрібно розглянути показники F1 − F8 і визначити, скільки показників F1 − F6 мають значення менше 3 і скільки показників F7, F8 мають значення більше 3.

Якщо загальна кількість менша або дорівнює 2, слідує використовувати 20 люд.-г. на одну UCP, якщо 3 або 4 − 28. Якщо загальна кількість дорівнює 5 або більше, слід внести зміни в сам проект, в протилежному випадку ризик провалу дуже високий.

T=UCP*кількість люд.-год

t_роз=2,5 × Т^N3

Модель композиції додатку

Модель композиції є однієї з конструктивних моделей вартості СОСОМО II.

Параметри даної моделі визначались на основі статистичного аналізу реальних результатів великої кількості проектів.

Модель композиції використовується на ранній стадії розробки ПЗ, коли:

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

Модель композиції додатку орієнтована на застосуванні об’єктних вказівників.

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

Модель композиції додатку

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

Оцінка кількості об’єктних вказівників

​

​

с

с

с

с

с

с

с

с

с

с

с

с

с

Модель композиції додатку

Оцінка складності екрана

Оцінка складності звіта

Модель композиції додатку

Модель композиції додатку

Оцінка зрілості розробки

​

Метод PERT

Інженерний метод оцінки трудоємності проекту PERT оснований на характеристиках 3 оцінок:

Mi — найбільш вірогідна оцінка трудовитрат.

Oi — мінімально можливі трудовитрати на реалізацію пакета робіт. Ні один ризик не реалізувався. Швидше точно не зробимо. Вірогідність того, що ми вкладемось в ці витрати, рівно 0.

Pi — песиместична оцінка трудовитрат. Всі ризики реалізовались.

Оцінку середнньої трудоємності по кожному елементарному пакету можна визначити за формулою:

Ei = (Pi + 4Mi + Oi)/6.

Для розрахунку середньоквадратичного відхилення використовується формула:

CKOi = (Pi - Oi)/6.

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

Е = ∑ Ei

Метод PERT

Метод PERT

Високорівнева архітектура J2EE фреймворка для розробки додатку.

Метод PERT

Високорівнева архітектура реалізовувала стандартний паттерн MVC, кожний з компонентів якого мав «точки розширення» для прикладної розробки, які на рисунку виділені червоним.

Такими точками розширення є:

Користувацький екран (UI Form), який збирався з готових візуальних компонентів.

Обробники(Action), які оброблювали на сервері додатків події від активних візуальних компонентів, які входять у склад екрану.

Об’єкти (Business Obj), які моделювали прикладну область, і до яких звертались обробники подій.

Новий додаток містить 20 користувацьких екранів, 60 обробників подій, 16 нових бізнес-об’єктів і 40 нових бізнес-методів.

​

Метод PERT

Визначити:

1. Ei для кожного елементарного пакету

2. СКОі - середньоквадратичне відхилення для кожного пакету

3. Середня трудоємність робіт по кодуванню

4. Середнєквадратичне відхилення для оцінки сумарної трудоємності.

5. Оцінку сумарної трудоємності проекта, яку ми не перевищемо з вірогідністю 95%

​

​