Жукова

Реферат

Тема: Оцінка складності розробки програмного забеспечення за об'єктно-ориентованою моделлю

Зміст

ВСТУП
1. Актуальність теми
2. Зв'язок роботи з науковими програмами, планами, темами
3. Цілі та задачі розробки
4. Передбачувана наукова новизна
5. Практичне значення отриманих результатів
6. Огляд розробок і досліджень по темі — огляд існуючих метрик
ВИСНОВКИ
СПИСОК ЛІТЕРАТУРИ

ВСТУП

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

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

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

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

1. Актуальність теми

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

Необхідно виділити певні якісні і кількісні характеристики ОО моделі, які дозволяють ще на етапі її розробки оцінити обсяг трудовитрат по реалізації, доробки та супроводу даної моделі.

2. Зв'язок роботи з науковими програмами, планами, темами

Кваліфікаційна робота магістра виконується протягом 2009-2010 рр. згідно з науковим напрямком кафедри «Автоматизовані Системи Управління» Донецького національного технічного університету.

3. Цілі та задачі розробки

Цілями оцінки якості ОО моделі є:

1. Визначити точку, коли необхідно припинити аналіз і проектування моделі й почати реалізацію ПЗ.
2. Підвищення якості розроблюваного ПЗ.
3. Скорочення часу на розробку ПЗ.
4. Виявлення кращої ОО моделі серед різних запропонованих варіантів.

Рисунок 1. Процесс функціонування системи, що ілюструє рух інформаціі. Анімація складається з 8 кадрів з затримкой у 50мс між кадрами; затримка для повторення складає 0мс; кількість циклів повторення не обмежено; обсяг 99,77кБ.

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

1. Виділення з вивчених критеріїв оцінки ГО моделі найбільш актуальних і гнучких у застосуванні до різних видів систем.
2. Вивчити відображення виділених параметрів на складності розробки програмного забезпечення по ГО моделі.
3. Розробити систему оцінки складності розробки програмного забезпечення по об'єктно-орієнтованої моделі.

4. Передбачувана наукова новизна

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

5. Практичне значення отриманих результатів

Отримана в результаті розробок система буде затребувана фахівцями, які працюють з об'єктно-орієнтованими системами, а зокрема розробниками таких систем.

6. Огляд розробок і досліджень по темі — огляд існуючих метрик

Метрика Холстеда

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

• — NUOprtr (Number of Unique Operators) — число унікальних операторів програми, включаючи символи — роздільники, імена процедур і знаки операцій (словник операторів);
• — NUOprnd (Number of Unique Operands) — число унікальних операндів програми (словник операндів);
• — Noprtr (Number of Operators) — загальна кількість операторів в програмі;
• — Noprnd (Number of Operands) — загальна кількість операндів у програмі.

Спираючись на ці характеристики, одержувані безпосередньо при аналізі вихідних текстів програм, М. Холстед вводить такі оцінки:

• — Словник програми (Halstead Program Vocabulary) HPVoc = NUOprtr + NUOprnd;
• — Довжина програми (Halstead Program Length) HPLen = Noprtr + Noprnd;
• — Обсяг програми (Halstead Program Volume) HPVol = HPLen log2 HPVoc.

Далі Холстед вводить складність програми (2.1),

Hdiff = NUOprtr/2* (Noprnd / NUOprnd) (2.1)
Heff = Hdiff* HPVol (2.2)

Використовуючи Hdiff, Холстед вводить оцінку Heff (2.2), за допомогою якої описуються зусилля програміста при розробці.

Графічне представлення програм МакКейбом

Друга, найбільш представницька, група оцінок складності програм — метрики складності потоку керування програм. Як правило, за допомогою цих оцінок оперують або щільністю керуючих переходів усередині програм, або взаємозв'язками цих переходів. І в тому, і в іншому випадку програма представляється у вигляді керуючого графа. Вперше графічне представлення програм було запропоновано МакКейб. Основний метрикою складності він пропонує вважати цікломатіческую складність графа програми, або, як її ще називають, цікломатіческое число МакКейб, що характеризує трудомісткість тестування програми. Для обчислення цікломатіческого числа МакКейб CC (Cyclomatic Complexity) застосовується формула (2.3).

CC = L — N + 2P (2.3)
де L — число дуг орієнтованого графа; N — кількість вершин; P — число компонентів зв'язності.

До метрик складності також відносяться:

• — NORM (Number Of Remote Methods) — кількість викликаються віддалених методів. При формуванні значення цієї метрики проглядаються всі конструктори і методи класу, і підраховується кількість викликаються віддалених методів. Вилученим методом є метод, який не визначено в класі і його батьків.
• — RFC (Response For Class) — відгук на клас. Кількість методів, які можуть викликатися екземплярами класу. Ця метрика обчислюється як сума кількості локальних методів і кількості віддалених методів.
• — WMPC1 (Weighted Methods Per Class 1) — зважена насиченість класу. Дає відносну міру його складності; якщо вважати що всі методи мають однакову складність, то це буде просто кількість методів у класі. Кількість методів та їх складність пов'язані для визначення часу і зусиль, які будуть потрібні для розробки та підтримки класу. Для розрахунку даної метрики використовуються тільки методи, визначені в конкретному класі, всі методи, які успадковуються від батьківського класу, не включаються.
• — WMPC2 (Weighted Methods Per Class 2) Ця метрика є мірою складності класу, який вважає, що клас з великою кількістю методів, ніж інший є більш складним, і що метод з великою кількістю параметрів також є більш складним. Для розрахунку даної метрики використовуються тільки методи визначені в конкретному класі, всі методи, які успадковуються від батьківського класу, не включаються.

У цю групу метрик також потрапляють базові метрики:

• — LOC (Lines Of Code) — кількість рядків коду.
• — NOC (Number Of Classes) — кількість класів.

Метрики по Чідамберу і Кемереру

Новий набір метрик програмного забезпечення для ОО проектування розробили і здійснили Чідамбер і Кемерер. Ці показники базувалися на теорії виміру, а також відображають точки зору опитаних ОО розробників.

• — Методи ваги за клас (WMC) Зважені Методи Класу (WMC) визначені як сума методів класу і призначені, щоб порахувати загальну складність методів у даному класі. Такий показник може використовуватися для обчислення кількості внутрішніх методів одного класу і складнощі внутрішніх методів класу.
• — Глибина Дерева спадкування (DIT)
• — Відповідь для Класу (RFC) є кількістю методів, які можуть виконатися у відповідь на лист, надісланий об'єкту в межах цього класу до одного рівня вкладення.
• — Число дочірніх записів (NOC). Цей показник визначено як число безпосередніх підкласів, підпорядкованих класу в ієрархії класу.
• — Нестача зв'язності методів (LCOM). Зв'язність — це ступінь взаємодії між елементами окремого модуля, характеристика його насиченості. Найменш бажаною є зв'язність за випадковим принципом, коли в одному модулі збираються абсолютно незалежні абстракції. Зв'язаність об'єктів — міра їх взаємозалежності. Розробники прагнуть проектувати слабо зв'язані об'єкти, оскільки вони мають більше шансів на повторне використання. Високе значення цієї метрики говорить про високу зв'язності методів — це означає, що будуть потрібні великі зусилля при тестуванні цих методів, так як методи можуть впливати на одні й ті ж атрибути класу. Це також говорить про низьку готовність до повторного використання.
• — Зв'язок між об'єктами (CBO) є числом пов'язаних пар ненаследуемих класами.
• — Кількість класів предків (NAC) визначається як загальна кількість класів предка, від яких клас успадковувався в ієрархії успадкування класу.
• — Число відбуваються класів (NDC) визначено як загальна кількість відбуваються класів (підкласів) класу. Атрибути класу, які охоплює NOC — це число класів, які можуть потенційно бути під впливом класу через наслідування.
• — Число локальних методів (NLM), визначених у класі, і які доступні поза класом. Он отличается от показателя WMC. Він відрізняється від показника WMC. Этот атрибут важен для использования класса в ОО проектировании в связи с тем, что он указывает размер локального интерфейса класса, через который другие классы могут использовать данный класс. Цей атрибут важливий для використання класу в ГО проектуванні в зв'язку з тим, що він вказує розмір локального інтерфейсу класу, через який інші класи можуть використовувати даний клас.
• — Складність методу класу (CMC) визначена як сума внутрішньої структурної складності всіх локальних методів. Незалежно від того, видимі чи вони поза класом. Це визначення по суті таке ж, як перше визначення показника WMC. Однак це суттєво різні показники, тому що вони фіксують два незалежних атрибута класу. Однак є деяка спільність у цих двох показниках — вони зачіпають обсяг сил, потрібний для проектування, здійснення, перевірки і підтримки класу.
• — Зв'язок через абстрактний тип даних (CTA) — загальна кількість класів, які використовуються як абстрактні типи даних в оголошенні атрибутів класу.
• — Зв'язок через передачу повідомлень (CTM) — це число різних повідомлень, посланих з класу в інші класи, виключаючи повідомлення, послані в об'єкти, створені локально в методах класу. Два класи можуть бути з'єднані, шляхом посилки повідомлення в об'єкт іншого класу, не об'єднуючи два класи через успадкування або абстрактний тип даних.

ВИСНОВКИ

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

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

1. Покращення розуміння якості продукту;
2. Оцінка ефективності процесу конструювання;
3. Поліпшення якості роботи на етапі проектування.

СПИСОК ЛІТЕРАТУРИ

1. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Издательство Питер, Санкт-Петербург, 2001.
2. М. Холстед. Начала науки о программах. Москва, 1981
3. Review of Complexity Metrics for Object Oriented Software Products, International Journal of Computer Science and Network Security, VO 314 L.8 No.11 — November 2008.
4. World Academy of Science, Engineering and Technology 23. A Metric-Set and Model Suggestion for Better Software Project Cost Estimation. 2006
5. Object Oriented Metrics (A Survey Approach), Seyyed Mohsen Jamali, Department of Computer Engineering Sharif University of Technology — January 2006.
6. Kan, S.H.: Metrics and Models in Software Quality Engineering. Adisson Wesley – 2002.
7. E. Dijkstra. Programming Considered as a Human Activity. Classics in Software Engineering. New York, Yourdon Press, 1979.
8. Corritore C., Wiedenbeck S. Direction and Scope of Comprehension-Related Activities by Procedural and Object-Oriented Programmers: An Empirical Study, Proceedings of the 8th
9. International Workshop on Program Comprehension (IWPC'00). 2000
10. Centre for Systems and Software Engineering, Faculty of Business, Computing and Information Management, London South Bank University. Ripple Effect: A Complexity Measure for Object Oriented Software, 2007
11. Homepage of the Subject-Oriented Programming Project, IBM Thomas J. Watson Research Center, YorktownHeights, New York, http://www.research.ibm.com/sop/
12. Black, S.E.: Computation of Ripple Effect Measures for Software. Ph.D. thesis, London South Bank University, London, UK, 2001
13. Black, S.E., Rosner, P.E.: Measuring Ripple Effect for the Object Oriented Paradigm. IASTED International Conference on Software Engineering, 15th-17th Innsbruck, Austria, February 2005

При написанні цього автореферату магістерська робота ще не завершена. Остаточне завершення: 1 грудня 2010 р. Повний текст роботи та матеріали за темою можна отримати у автора або його керівника після зазначеної дати.

© ДонНТУ 2010, Жукова Д.К.