Жукова

Реферат

Тема: Оцена сложности разработки программного обеспечения по объектно-ориентированной модели

Содержание

ВВЕДЕНИЕ
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. Этот атрибут важен для использования класса в ОО проектировании в связи с тем, что он указывает размер локального интерфейса класса, через который другие классы могут использовать данный класс.
• — Сложность метода класса (CMC) определена как сумма внутренней структурной сложности всех локальных методов. Независимо от того, видимы ли они вне класса. Это определение по существу такое же, как первое определение показателя WMC. Однако это существенно различные показатели, потому что они фиксируют два независимых атрибута класса. Однако есть некоторая общность в этих двух показателях — они затрагивают объем сил, требуемый для проектирования, осуществления, проверки и поддержания класса.
• — Связь через абстрактный тип данных (CTA) — общее количество классов, которые используются как абстрактные типы данных в объявлении атрибутов класса.
• — Связь через передачу сообщений (CTM) — это число различных сообщений, посланных из класса в другие классы, исключая сообщения, посланные в объекты, созданные локально в методах класса. Два класса могут быть соединены, путем посылки сообщения в объект другого класса, не объединяя два класса через наследование или абстрактный тип данных.

ВЫВОДЫ

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

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

• — улучшение понимания качества продукта;
• — оценка эффективности процесса конструирования;
• — улучшение качества работы на этапе проектирования.

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

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. J. Watson Research Center, Yorktown Heights, New York, Homepage of the Subject-Oriented Programming Project, IBM — 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, Жукова Д.К.