Размещено на http://www.allbest.ru/

Содержание

Определения, обозначения и сокращения

Введение

1. Аналитический обзор литературы по предметной области

1.1 Основные понятия в области сложности программ

1.2 Анализ методов оценки сложности программ

1.3 Анализ существующих программных средств оценки сложности программ

1.4 Постановка задачи

2. Математические модели, положенные в основу программного средства для оценки сложности программ

2.1 Метрики размера программ

2.1.1 Простейшие объемные метрики

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

2.2 Метрики сложности потока управления программ

2.2.1 Метрика Маккейба

2.2.2 Метрика Майерса

2.2.3 Метрика Джилба

2.3 Метрики сложности потока данных

2.3.1 Метрика обращения к глобальным переменным

2.3.2 Спен

2.3.3 Метрика Чепина

2.4 Комплексные меры сложности программ

3. Обоснование технических приемов программирования

3.1 Выбор операционной системы

3.2 Среда разработки приложений Borland Delphi 7.0

4. Разработка программного средства для оценки сложности программ

4.1 Структура разрабатываемого программного средства

4.2 Разработка алгоритмов

4.2.1 Алгоритм расчёта простейших объёмных метрик

4.2.2 Алгоритм расчёта метрик Холстеда

4.2.3 Алгоритм расчёта метрики Маккейба

4.2.4 Алгоритм расчёта метрики Майерса

4.2.5 Алгоритм расчёта метрики Джилба

4.2.6 Алгоритм расчёта метрики обращения к глобальным переменным

4.2.7 Алгоритм расчёта спена

4.2.8 Алгоритм расчёта метрики Чепина

4.2.9 Алгоритм расчёта комплексной меры сложности программы

4.3 Структура классов программного средства для оценки сложности программ

5. Методика работы пользователя с программным средством для оценки сложности программ

5.1 Комплектация

5.2 Описание элементов главного меню

5.3 Работа с программным средством для оценки сложности программ

5.4 Окна Метрик

5.5 Горячие клавиши

6. Технико-экономическое обоснование разработки программного средства для оценки сложности программ

6.1 Общая характеристика программных средств вычислительной техники

6.2 Расчёт сметы затрат и отпускной цены на ПС

6.3 Расчет прогнозируемого экономического эффекта от использования разрабатываемого программного средства у пользователя

6.4 Расчет экономического эффекта от применяемого программного средства (у пользователя)

6.5 Выводы

7. Охрана труда и экологическая безопасность

Заключение

Список использованных источников

Определения, обозначения и сокращения

В настоящей пояснительной записке применяются следующие определения и сокращения:

ПСОСП - программное средство для оценки сложности программ;

ПО - программное обеспечение;

ПС - программное средство;

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

Метрика сложности программ - количественная мера оценки сложности программного обеспечения.

Введение

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

На современном этапе развития не вызывает сомнения необходимость развития теоретических основ оценивания качества программных средств (ПС). Во-первых, постоянное наращивание сложности ПС, как правило, ведет к увеличению числа исходных ошибок в тексте программы, что снижает ее качество. Во-вторых возрастает вероятность увеличения уязвимостей в ПС, которыми может воспользоваться злоумышленник. Кроме того многообразие ПС, имеющих сходное функциональное назначение, создает жесткую конкуренцию на рынке программной продукции. Число ПС одного класса достигает сотен, а если учесть еще наличие различных версий одного и того же ПС, то и тысяч единиц. Возникает вопрос, как выбрать необходимое ПС, которое будет оптимально простым и надёжным. На первый взгляд может показаться, что старые версии ПС следует безоговорочно «сбрасывать со счетов». Однако, как показывает практика, зачастую новые версии ПС - «сырые» и уступают по качеству предыдущим. К тому же, как правило, требования последних версий ПС к аппаратным средствам жестче, что при выборе ПС для работы на компьютере, заданной комплектации, является одним из важнейших критериев выбора.

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

Одной из основных составляющих качества ПС является его сложность.

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

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

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

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

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

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

В свою очередь, сложность самой программы зависит от: её размера, структур данных; структур управления, определяемых логикой программы; правильного ее разбиения на модули; внутренних связей каждого модуля; межмодульных связей в программе. Именно поэтому при оценке сложности важно получить некоторое числовое значение, на основании которого можно сравнить несколько программ.

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

1. Аналитический обзор литературы по предметной области

1.1 Основные понятия в области сложности программ

Современные программные проекты характеризуются их сложностью. Трудоемкость программных разработок сильно зависит от уровня сложности проекта и является характеристикой, даже приблизительную оценку которой получить весьма тяжело, особенно на ранних стадиях проектов. Сложность программного обеспечения - отнюдь не случайное его свойство. Как сказано в работе [1], сложность вызывается четырьмя основными причинами:

- сложностью реальной предметной области, из которой исходит заказ на разработку;

- трудностью управления процессом разработки;

- необходимостью обеспечить достаточную гибкость программы;

- неудовлетворительными способами описания поведения больших дискретных систем.

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

Эта внешняя сложность обычно возникает из-за "нестыковки" между пользователями системы и ее разработчиками: пользователи с трудом могут объяснить в форме, понятной разработчикам, что на самом деле нужно сделать. Бывают случаи, когда пользователь лишь смутно представляет, что ему нужно от будущей программной системы. Это в основном происходит не из-за ошибок с той или иной стороны; просто каждая из групп специализируется в своей области, и ей недостает знаний партнера. У пользователей и разработчиков разные взгляды на сущность проблемы, и они делают различные выводы о возможных путях ее решения. На самом деле, даже если пользователь точно знает, что ему нужно, однозначно зафиксировать все его требования достаточно трудно. Обычно они отражены на многих страницах текста, "разбавленных" немногими рисунками. Такие документы трудно поддаются пониманию, они открыты для различных интерпретаций и часто содержат элементы, относящиеся скорее к дизайну, чем к необходимым требованиям разработки.

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

Трудности управления процессом разработки. Основная задача разработчиков состоит в создании иллюзии простоты, в защите пользователей от сложности описываемого предмета или процесса. Размер исходных текстов программной системы отнюдь не входит в число ее главных достоинств, поэтому программисты стараются делать исходные тексты более компактными, изобретая хитроумные и мощные методы, а также используя среды разработки уже существующих проектов и программ. Однако новые требования для каждой новой системы неизбежны, а они приводят к необходимости либо создавать много программ "с нуля", либо пытаться по-новому использовать существующие. Всего 20 лет назад программы объемом в несколько тысяч строк на ассемблере выходили за пределы человеческих возможностей. Сегодня обычными стали программные системы, размер которых исчисляется десятками тысяч или даже миллионами строк на языках высокого уровня. Ни один человек не в состоянии полностью понять такую систему. Даже если правильно разложить ее на составные части, все равно получатся сотни, а иногда и тысячи отдельных модулей. Поэтому такой объем работ потребует привлечения команды разработчиков, в идеале как можно меньшей по численности. Но какой бы она ни была, всегда будут возникать значительные трудности, связанные с организацией коллективной разработки. Чем больше разработчиков, тем сложнее связи между ними и тем сложнее координация, особенно если участники работ географически удалены друг от друга, что типично в случае очень больших проектов.

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

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

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

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

2. Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен, и в большей степени оставляется на усмотрение исследователя.

3. Внутрикомпонентная связь обычно сильнее, чем связь между компонентами.

4. Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных.

5. Любая работающая сложная система является результатом развития работавшей более простой системы. Сложная система, спроектированная с нуля никогда не заработает. Следует начинать с работающей простой системы. Поскольку программа является сложной системой, имеет смысл выделить в ней подсистемы (компоненты) и разрабатывать их либо независимо друг от друга, обговорив лишь детали интерфейса между компонентами. В этом случае к работе может приступить либо группа разработчиков (параллельная работа), либо один и тот же человек будет работать над компонентами в разное время (последовательная работа). Это позволит не только управлять процессом разработки, но и сделает программу более ясно воспринимаемой и лучше модифицируемой впоследствии.

1.2 Анализ методов оценки сложности программ

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

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

В свою очередь, сложность самой программы зависит от: размера программы; ее структур данных; структур управления, определяемых логикой программы; правильного ее разбиения на модули; внутренних связей каждого модуля; межмодульных связей в программе.

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

Поэтому разработка метрик и мер, способных ранжировать программы по некоторому критерию качества, и создание программных инструментов, обеспечивающих их вычисление - важные проблемы метрологии качества программ.

Метрики сложности программ можно разделить на два больших класса: статические и динамические [2].

Статические метрики, в свою очередь, можно разделить на четыре типа: объемные, топологические, потока данных и комплексные.

Объемные метрики наиболее просты и, очевидно, поэтому получили широкое распространение.

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

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

Данный вид метрик представлен простейшими объемными мерами и мерами Холстеда.

К простейшим объемным метрикам можно отнести:

L, - число строк в программе, включая комментарии;

S - число исполняемых операторов;

U - число программных модулей: подпрограмм, функций и т. д.;

S/U _ средний размер программного модуля.

Меры Холстеда основаны на следующих индикаторах:

з1, з2 - число типов операторов и различных операндов;

N1, N2 - число всех операторов и операндов.

В качестве наиболее известных мер Холстеда можно привести следующие:

словарь программы - n = n₁ + n₂, (1.1)

длина программы - N = N₁ + N₂, (1.2)

объем программы - V = N * log₂n; (1.3)

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

Топологические меры сложности (Метрики сложности потока управления программ). Как правило, с помощью этих оценок оперируют либо плотностью управляющих переходов внутри программ, либо взаимосвязями этих переходов.

И в том и в другом случае стало традиционным представление программ в виде управляющего ориентированного графа G=(V,E), где V - вершины, соответствующие операторам, а E - дуги, соответствующие переходам.

Появились в результате неспособности мер Холстеда и аналогичных им учитывать сложность структур управления.

Мера Мак-Кейба. Является наиболее известной и популярной мерой оценки сложности программ. Цикломатической сложностью программы с управляющим графом G (n вершин, m дуг и одна компонента связности) называется величина:

(1.4)

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

Критика по адресу меры Мак-Кейба и желание охватить другие характеристики программ привели к созданию новых мер, часть из которых является вариантами цикломатической сложности. Таковыми являются меры сложности Хансена, интервальная и топологическая меры.

Метрика Мак-Кейба является одной из наиболее популярных, и следовательно часто используемых метрик расчёта сложности программ. В 1975 году Rome Laboratory профинансировала исследование метрики, очень близкой к метрике Мак-Кейба(1976г.). Фактически, работа Мак-Кейба являлась дубликатом более ранних исследований, произведенных в Rome Laboratory. Мак-Кейб представил свою работу в более доступной и читабельной форме. Поэтому именно его работа получила такое широкое распространение. Если бы Мак-Кейб не опубликовал свои исследования, то его метрика возможно называлась бы метрика сложности Салливана (Sullivan Complexity Metric)[3].

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

Довольно крупную проблему составляла оценка сложности больших систем, включающих в себя несколько подсистем. Салливан, как позже и Мак-Кейб, решил представить сложность всей системы как сумму сложностей управляющих графов всех подсистем. Результат этого представления впоследствии был представлен как определение:

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

Также Салливан обнаружил, что если программа написана с использованием простых последовательностей, и использует IF-THEN-ELSE для условия и DO-WHILE для итерации, то итоговая сложность программы равно сумме всех IF и WHILE.

Узловая мера (KNOTS) определена только для неструктурированных программ с расположением одного оператора в строке.

Меры, основанные на учете потока данных

Меры сложности, основанные на концепции информационных потоков между компонентами системы, описаны С. Хенри и Д. Кафурой и содержат информационную сложность процедуры, модуля и информационную сложность модуля относительно структуры данных.

Мера Овиедо определяет сложность программы только через межлучевой поток данных (управляющий граф состоит из непересекающихся участков операторов - лучей). Мера Тая исследует влияние DU-пар (буквой D обозначается определение данных, а U - их использование) на выбор той ветви программы, которая исполняется.

Также к мерам сложности потока данных относятся метрика обращения к глобальным переменным, спен и метрика Чепина, реализации которых будут представлены ниже.

1.3 Анализ существующих программных средств оценки сложности программ

В настоящее время количество программ рассчитывающих сложность программного обеспечения очень мало. Большинство из них являются частью различных сред разработки.

Примером одной из таких частей является Vi Metrics, являющаяся частью среды графического программирования LabVIEW компании National Instruments.

LabVIEW - интегрированная среда разработчика для создания интерактивных программ сбора, обработки данных и управления периферийными устройствами.

LabVIEW - графическая система программирования на уровне функциональных блок-диаграмм, позволяющая графически объединять программные модули в виртуальные инструменты (Virtual Instruments - VI).Таким образом, LabVIEW дает возможность избежать сложностей обычного "текстового" программирования.

VI Metrics оценивает сложность программ, реализованных на LabVIEW и помогает рассчитать размеры полученного в итоге проекта. Поскольку разработка производится посредством диаграмм LabVIEW, то Vi Metrics производит оценку посредством собственных метрик. Таковыми являются:

1. Количество узлов

2. Количество структур

3. Количество диаграмм

4. Максимальная глубина вложенности диаграмм

Рисунок 1.1. - Результат работы VI Metrics

На рисунке 1.1 изображен результат работы программы Vi Metrics.

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

- невозможность добавить собственных метрик;

- отсутствие некоторой комплексной величины, позволяющей в целом оценить сложность программы;

- Невозможность установить VI Metrics отдельно от среды LabVIEW;

Ещё одним программным средством оценки сложности программ является Logiscope компании TeleLogic.

Данное программное средство предназначено для оценки качества программ.

Качество разделяется на следующие характеристики:

-функциональность(functionality);

- надежность(reliability);

- используемость (usability);

- эффективность (efficiency);

- восстанавливаемость(maintainability);

- мобильность(portability);

Качество программ в Logiscope классифицируется как:

-Великолепное качество. Абсолютно все условия обеспечения качества удовлетворяются.

- Хорошее качество. Почти все условия обеспечения качества удовлетворяются.

- Неплохое качество. Большая часть условий обеспечения качества выполняется.

- Неудовлетворительное качество. Большая часть условий обеспечения качества не выполняется.

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

Telelogic Logiscope заключает в себе расчёт следующих метрик сложности:

1. Метрики Холстеда(длина программы, словарь программы, расчётная длинна программы, объем программы, затруднительность программы, уровень программы)

2. Число вложенностей.

3. Количество макро инструкций.

4. Средний размер операторов.

5. Частота использования комментариев.

Достоинства Telelogic Logiscope:

1. Универсальность. Данное ПС позволяет оценить сложность программ, реализованных на C/C++, JAVA, ADA.

2. Совместимость с основными стандартами, оговаривающими качество программ

Однако несмотря на достоинства существует ряд недостатков.

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

2. Невозможно исследовать программы, реализованные на языках Паскаль(Pascal).

3. Всего четыре шкалы оценки качества программ.

4. Отсутствует возможность добавления дополнительных метрик(открытая архитектура),

5. Набор метрик недостаточен.

1.4 Постановка задачи

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

Программное средство должно выполнять следующие функции:

1. Реализация следующих метрик:

- простейшие объемные метрики;

- метрики Холстеда;

- метрика Маккейба;

- метрика Майерса;

- метрика Джилба;

- метрика обращения к глобальным переменным;

- вычисление спена;

- метрика Чепина;

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

3. Возможность построения графической и текстовой информации для более простого визуального восприятия.

Реализованное программное средство должно иметь интуитивно понятный интерфейс, быть удобно в эксплуатации.

2. Математические модели, положенные в основу программного средства для оценки сложности программ

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

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

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

При оценке сложности программ, как правило, выделяют три основные группы метрик:

- метрики размера программ

- метрики сложности потока управления программ

- метрики сложности потока данных программ

2.1 Метрики размера программ

2.1.1 Простейшие объемные метрики

К ним можно отнести:

L, - число строк в программе, включая комментарии;

S - число исполняемых операторов;

U - число программных модулей: подпрограмм, функций и т. д.;

S/U - средний размер программного модуля.

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

Основу метрик Холстеда составляют четыре измеряемых характеристики программы:

n1 - число уникальных операторов программы, включая символы-

разделители, имена процедур и знаки операций (словарь операторов);

n2 - число уникальных операндов программы (словарь операндов);

N1 - общее число операторов в программе;

N2 - общее число операндов в программе.

Опираясь на эти характеристики, получаемые непосредственно при анализе исходных текстов программ, М. Холстед ввел следующие оценки:

словарь программы:

n1=n1+n2, (2.1)

длину программы:

N=N1+N2, (2.2)

объем программы:

V=N*log2(n) (2.3)

расчётную длину программы:

CN = n1*log₂n1 + n2*log₂n2 (2.4)

трудоемкость кодирования:

 (2.5)

уровень программы:

L = 1/D (2.6)

трудность понимания:

E = V/L (2.7)

информационное содержание:

I = V*L (2.8)

частоту словаря:

VOCF = (2.9)

2.2 Метрики сложности потока управления программ

2.2.1 Метрика Маккейба

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

Для вычисления цикломатического числа Маккейба Z(G) применяется формула

Z(G)=e-v+2p, (2.10)

где e - число дуг ориентированного графа G;

v - число вершин;

p - число компонентов связности графа.

Число компонентов связности графа можно рассматривать как количество дуг, которые необходимо добавить для преобразования графа в сильно связный. Cильно связным называется граф, любые две вершины которого взаимно достижимы. Для графов корректных программ, т. е. графов, не имеющих недостижимых от точки входа участков и "висячих" точек входа и выхода, сильно связный граф, как правило, получается путем замыкания дугой вершины, обозначающей конец программы, на вершину, обозначающую точку входа в эту программу.

По сути Z(G) определяет число линейно независимых контуров в Сильно связном графе. Иначе говоря, цикломатическое число Маккейба показывает требуемое количество проходов для покрытия всех контуров сильно связного графа или количество тестовых прогонов программы, необходимых для исчерпывающего тестирования по критерию "работает каждая ветвь".

Для программы, граф которой изображен на рисунке 2.1, цикломатическое число при e=10, v=8, p=1 определится как Z(G)=10-8+2=4.

Цикломатическое число зависит только от количества предикатов, сложность которых при этом не учитывается. Например, имеется два оператора условия:

IF X>0

THEN X=A;

ELSE;

и IF (X>0 & FLAG='1'B)!

(X=0 & FLAG='0'B)

THEN X=A;

ELSE;



Рисунок 2.1 - Пример управляющего графа программы

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

Общий подход состоит в оценке сложности программы с помощью вычисления числа линейно-независимых путей, цикломатической сложности V(G), а также управления размером программ с помощью ограничения V(G) и использования V(G) как основы для методологии тестирования. Маккейб обнаружил, что разумной верхней границей для цикломатической сложности является 10. Если программисты переступают эту границу, им следует или переписать программу, или разбить ее на модули.

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

2.2.2 Метрика Майерса

Исходя из этого Г. Майерс предложил расширение метрики Маккейба. Суть подхода Г. Майерса состоит в представлении метрики сложности программ в виде интервала [Z(G), Z(G)+h]. Для простого предиката h=0, а для n-местных предикатов h=n-1. Таким образом, первому оператору соответствует интервал [2,2], а второму - [2,6].

По идее такая метрика позволяет различать программы, представленные одинаковыми графами. К сожалению, информация о результатах использования этого метода отсутствует, поэтому ничего нельзя сказать о его применимости.

2.2.3 Метрика Джилба

Одной из наиболее простых, но, как показывает практика, достаточно эффективных оценок сложности программ является метрика Т. Джилба, в которой логическая сложность программы определяется как насыщенность программы выражениями типа IF-THEN-ELSE. При этом вводятся две характеристики:

CL - абсолютная сложность программы, характеризующаяся количеством операторов условия;

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

CLI - характеристикой максимального уровня вложенности оператора IF

2.3 Метрики сложности потока данных

Третья группа метрик сложности программ - метрики сложности потока данных, т.е. использования, конфигурации и размещения данных в программах.

2.3.1 Метрика обращения к глобальным переменным

Рассмотрим метрику, связывающую сложность программ с обращениями к глобальным переменным.

Пара "модуль-глобальная переменная" обозначается как (p,r), где p - модуль, имеющий доступ к глобальной переменной r. В зависимости от наличия в программе реального обращения к переменной r формируются два типа пар "модуль-глобальная переменная": фактические и возможные. Возможное обращение к r с помощью p показывает, что область существования r включает в себя p.

Характеристика Aup говорит о том, сколько раз модули Up действительно получали доступ к глобальным переменным, а число Pup - сколько раз они могли бы получить доступ.

Отношение числа фактических обращений к возможным определяется

Rup = Aup/Pup.

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

К сожалению, пока нельзя сказать, насколько удобен и точен этот метод на практике, так как нет соответствующих статистических данных.

2.3.2 Спен

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

2.3.3 Метрика Чепина

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

Все множество переменных, составляющих список ввода-вывода, разбивается на 4 функциональные группы:

P - вводимые переменные для расчетов и для обеспечения вывода.

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

M - модифицируемые, или создаваемые внутри программы переменные.

C - переменные, участвующие в управлении работой программного модуля (управляющие переменные).

T - не используемые в программе ("паразитные") переменные. Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо учитывать ее в каждой соответствующей функциональной группе.

Далее вводится значение метрики Чепина:

Q = a1*P + a2*M + a3*C + a4*T; (2.11)

a1, a2, a3, a4 - весовые коэффициенты.

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

a1=1,

a2=2,

a4=0.5.

Весовой коэффициент группы T не равен 0, поскольку "паразитные" переменные не увеличивают сложность потока данных программы, но иногда затрудняют ее понимание. С учетом весовых коэффициентов выражение принимает вид:

Q = P + 2M + 3C + 0.5T (2.12)

2.4 Комплексные меры сложности программ

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

(2.13)

где: Mi - интересующие пользователя метрики;

Ri - весовые коэффициенты

3. Обоснование технических приемов программирования

3.1 Выбор операционной системы

Выбор операционной системы осуществлялся по следующим критериям:

а) интуитивно понятный графический интерфейс;

б) мощные графические возможности;

в) поддержка файловой операционной системы, которая должна обеспечить защиту файлов и надежность их хранения;

г) эффективное управление программными ресурсами;

д) встроенная поддержка современных технологий обработки, хранения и передачи данных;

е) наибольшая популярность среди пользователей.

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

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

3.2 Среда разработки приложений Borland Delphi 7.0

Рассматривая современные средства разработки приложений, можно заметить, что их развитие подчиняется определенным закономерностям и тенденциям.

Первой из таких тенденций является использование в программировании объектно-ориентированного подхода, позволившее осуществлять повторное использование кода с большей эффективностью, нежели при применении так называемого модульного программирования. Зачатки объектного подхода появились во многих популярных в 80-х годах средствах разработки, таких, например, как Clipper. Однако расцвет объектно-ориентированного программирования начался с появления языков Object Pascal и С++.

Следующей немаловажной тенденцией развития средств разработки являлось создание высокопроизводительных компиляторов и стремление использовать скомпилированный код. Известно, что последний обладает существенно более высокой производительностью, чем код интерпретируемый. Отметим, что наличие исполняемого файла как результата создания приложения не гарантирует, что созданный код не является интерпретируемым (типичные примеры средств разработки, создающих исполняемый файл с интерпретируемым кодом - Centura SQL Windows, Visual FoxPro, Clipper, Visual Basic, Developer-2000).

Третьей тенденцией развития инструментальных средств являлось создание визуальных средств проектирования пользовательских интерфейсов, что позволило ускорить работу над проектами, облегчить повторное использование кода и в определенной степени привлечь к созданию приложений начинающих программистов. Наиболее ярким примером такого средства явилось появление в середине 90-х годов Visual Basic, имеющего в своем составе элементы VBX, из которых можно было строить интерфейс приложения, просто размещая их на форме, а так же различных средств редактирования ресурсов типа Borland Resorse Workshop. Отметим, однако, что в случае Visual Basic пользователь вынужден был довольствоваться готовыми VBX-элементами, либо создавать их на языке С с помощью других средств разработки.

Следует отметить, что Borland Delphi представляет собой следствие влияния всех этих тенденций, так как сочетает в себе удобства визуальной среды разработки, объектно-ориентированный подход, разнообразие возможностей повторного использования кода, открытую архитектуру и высокопроизводительные компиляторы языка Object Pascal, являющегося на сегодняшний день одним из самых популярных языков программирования, а так же масштабируемый доступ к данным, хранящимся в различных СУБД, как настольных, так и серверных.

Delphi и С++ Builder стали одними из самых популярных на сегодняшний день инструментов для создания как настольных, так и корпоративных информационных систем благодаря уникальному сочетанию удобства разработки пользовательских интерфейсов, компонентной архитектуры, однотипности доступа к разнообразным базам данных, начиная от плоских таблиц формата dBase и Paradox и кончая серверными СУБД. Во многом именно наличие таких продуктов стимулировало достаточно безболезненный перенос в архитектуру клиент/сервер ряда информационных систем, модернизация которых иными средствами была бы сопряжена с большими трудовыми и материальными затратами.

За последние несколько лет создано огромное количество компонент для Delphi. Это богатство, накопленное разработчиками всего мира, сегодня способно удовлетворить самые причудливые запросы.

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

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

Среда программирования представляет собой несколько отдельных окон: меню и инструментальные панели, Object Inspector (в котором можно видеть свойства объекта и связанные с ним события), окна визуального построителя интерфейсов (Visual User Interface Builder), Object Browser (позволяющее изучать иерархию классов и просматривать списки их полей, методов и свойств), окна управления проектом (Project Manager) и редактора.[6]

Delphi содержит полноценный текстовый редактор типа Brief, назначения клавиш в котором соответствуют принятым в Windows стандартам, а глубина иерархии операций Undo неограниченна. Как это стало уже обязательным, реализовано цветовое выделение различных лексических элементов программы. Процесс построения приложения достаточно прост. Нужно выбрать форму (в понятие формы входят обычные, диалоговые, родительские и дочерние окна MDI), задать ее свойства и включить в нее необходимые компоненты (видимые и, если понадобится, неотображаемые): меню, инструментальные панели, строку состояния и т. п., задать их свойства и далее написать (с помощью редактора исходного кода) обработчики событий. Object Browser Окна типа Object Browser стали неотъемлемой частью систем программирования на объектно-ориентированных языках. Работа с ними становится возможной сразу после того, как вы скомпилировали приложение.

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

Visual Component Library (VCL) Богатство палитры объектов для построения пользовательского интерфейса - один из ключевых факторов при выборе инструмента визуального программирования. При этом для пользователя имеет значение как число элементов, включенных непосредственно в среду, так и доступность элементов соответствующего формата на рынке.

Компиляторы языка Pascal компании Borland никогда не заставляли пользователя подолгу ждать результатов компиляции. Производители утверждают, что на сегодняшний день данный компилятор - самый быстрый в мире. Компилятор, встроенный в Delphi позволяет обрабатывать до 390 тыс. строк исходного текста в минуту на машине Pentium-100. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL.

Следует отметить также, что благодаря опции оптимизации сегментов удается существенно сократить размер выполняемого файла. Можно запустить компилятор в режиме проверки синтаксиса. При этом наиболее длительная операция компоновки и изготовления исполняемого файла выполняться не будет.

Borland Delphi поставляется в трех вариантах, отличающихся функциональными возможностями и совместимых снизу вверх:

Standart - версия для начинающих программистов;

Proffessional - версия для профессиональных разработчиков, ориентирующихся на создание многопользовательских приложений;

Enterprice - версия для разработчиков, создающих корпоративные информационные системы, использующие данные, хранящиеся в серверных СУБД (Oracle, Sybase, MS SQL Server, IB Database, Informix, DB2), а так же, возможно, распределенную обработку данных в многозвенных системах.

4. Разработка программного средства для оценки сложности программ

4.1 Структура разрабатываемого программного средства

Обобщенная схема разрабатываемого ПС (рисунок 4.1) включает в себя следующие модули:

1) Модуль загрузки исходного текста. В данном модуле производится загрузка исходного текста анализируемой программы. Происходит это посредством вывода на экран диалогового окна открытия файлов. В этом диалоговом окне отфильтровываются все расширения, кроме *.pas, поскольку исходные тексты языков семейства Pascal имеют только такое расширение. После открытия файла его содержимое выводится на экран.

Рисунок 4.1 - Структура разрабатываемого ПС

2) Модуль преобразования текста. Данный модуль преобразовывает текст, полученный при загрузке в форму, удобную для анализа и расчётов. Поскольку исходный текст может быть не структуризирован, модуль преобразует его по принципу «один оператор - одна строка», например:

Исходный текст:

Program Hello; begin Write(`Hello'); end.

Преобразованный текст:

Program Hello;

begin

Write(`Hello');

end.

На этом этапе программы, содержащие несколько подпрограмм, разбиваются на отдельные файлы.

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

...