48462

Проверка функциональности программ

Лекция

Информатика, кибернетика и программирование

тестирование Аналитическая стахостическое детерминированное система Флойда система Дейстра система Хоара Метод не подвижности точки программы 3Понятие о системе Хоара Логика Хоара формальная система с набором логических правил предназначенных для доказательства корректности компьютерных программ Основной характеристикой логики Хоара является тройка Хоара.Оценки сложности программы LOC наработанный...

Русский

2013-12-10

124.5 KB

5 чел.

1.Проверка функциональности программ

1)Этапы разработки

   Реализация                            Интегрирование                Продукция

   компонентов                     (компенсация)                  (с демо примерами)

Самоконтроль                                                           Тестирование

 разработчика                                                          1)правильность сборки

(снизу вверх,                                                            2)правильность функционирования

 сверху вниз)

                                   Тестирование =                                                                  Испытание

                                   проверка  функциональности                                       1)демонстрация                             

                                   разными способами                                                       2)по программе

                                   на основании специфи-

                                   фикации компонента  

                                    (докум.)  

                     Цель

     Задачи                    Основные задачи

функции                                     задачи

                                                                подзадачи

                                                       

                                                            

                                                                           функции

2)Инструменты

Средства проверки функциональности

Динамические

Статистические

Тестирование

Верификация

Внешние

Внутренние

Эксперт.прос.

Потоки управ-

ления

Потоки

данных

Символ.

тести-рование

Аналитическая

стахостическое

детерминированное

система Флойда,

система Дейстра,

системаХоара

Метод не подвижности точки программы

3)Понятие о системе Хоара

Логика Хоара  формальная система с набором логических правил, предназначенных для доказательства корректности компьютерных программ

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

где P и Q являются утверждениями , а C  командой. P называется предусловием, а Q — постусловием. Если предусловие выполняется, команда делает верным постусловие. Утверждения являются формулами логики предикатов.

2.Оценки сложности программы

               

                                  LOC

    наработанный                          рабочий

       код                                               код

Количество строк исходного кода (Lines of Code – LOC, Source Lines of Code – SLOC) является наиболее простым и распространенным способом оценки объема работ по проекту.

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

  1.  количество «физических» строк кода – SLOC (используемые аббревиатуры LOC, SLOC, KLOC, KSLOC, DSLOC) – определяется как общее число строк исходного кода, включая комментарии и пустые строки (при измерении показателя на количество пустых строк, как правило, вводится ограничение – при подсчете учитывается число пустых строк, которое не превышает 25% общего числа строк в измеряемом блоке кода).
  2.  Количество «логических» строк кода – SLOC (используемые аббревиатуры LSI, DSI, KDSI, где «SI» - source instructions) – определяется как количество команд и зависит от используемого языка программирования. В том случае, если язык не допускает размещение нескольких команд на одной строке, то количество «логических» SLOC будет соответствовать числу «физических», за исключением числа пустых строк и строк комментариев. В том случае, если язык программирования поддерживает размещение нескольких команд на одной строке, то одна физическая строка должна быть учтена как несколько логических, если она содержит более одной команды языка.

Для метрики SLOC существует большое число производных, призванных получить отдельные показатели проекта, основными среди которых являются:

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

1)Представление о различных системах оценивания

Управляющий граф программы - граф G(V,A), где V(V1,… Vm) – множество вершин (операторов), A(A1,… An) – множество дуг (управлений), соединяющих операторы-вершины.

Анализ вызова подпрограмм

Типы узлов:

- условие

- операторные узлы

1)Представление о теории Холстеда и научных метриках

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

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

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

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

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

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

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

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

n1=n1+n2,

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

N=N1+N2,                     (1)

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

V=N*log2(n) (бит).           (2)

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

Далее М. Холстед вводит n* - теоретический словарь программы, т.е. словарный запас, необходимый для написания программы, с учетом того, что необходимая функция уже реализована в данном языке и, следовательно, программа сводится к вызову этой функции. Например, согласно М. Холстеду, возможное осуществление процедуры выделения простого числа могло бы выглядеть так:

CALL SIMPLE (X,Y),

где Y - массив численных значений, содержащий искомое число X.

Теоретический словарь в этом случае будет состоять из

n1* : {CALL, SIMPLE (...)},

n1*=2; n2* : {X, Y},

n2*=2,

а его длина, определяемая как

n* = n1* + n2*,

будет равняться 4.

Используя n*, Холстед вводит оценку V*:

V* = n* * log2 n*,    (3)

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

Критерий полноты

1)множество тестов покрыло все ребра

2)покрыты все вершины

3)выполнение всех путей

Ребра – линейные участки

Метод  Холстеда

η – сл.    N – ср.

η = η1 + η2     

V = N log η

= η*

V* = η* log N* = η* log η*

A = (V/V*) * V = V2/V*

T = s*A

3)ЯП – определение программных символов

  C, Pascal, PL/1….Java

  η* = p1 + p2 + j

  Create (F, “My-File”);

  if x > 0 then Put(x);

  else if x = 0 then Put (0.0);

  else Put (F, 1.0/x);

   end if;

4)Потенциальный объем модулей схемы программной системы

   

package Module is

            A: array (1…5) of integer;

             procedur h

package Group is

             C: constant Character:=’c’;

function f return character;

function g return integer;

end Group;

end Module;

p1

p2

j1

j2

j

η*

V*

f

0

1

1

1

1

2

4

8

g

0

1

1

4

2

3

6

h

0

0

0

0

0

0

2

2

Rest(Group)

0

1

2

2

2

3

5

10

Rest(Module)

0

1

0

0

0

1

3

6

 

V вместо W – объем разработки

W = Vm1 +Vm2 +…+ Vmm + )

V = V(η)

5)Объем разработки и работа программирования

  Aспс = ∑ Амод

6)Спецификация енергии программы

     =  / λ2 , λ- уровень языка (нормированный множитель)

λ <<1 – для языков ассемблера

λ ≈ 1 – для Фортрана 66

Еавто=  

Емод = ∑ Егрупп

Еструкт.групп =

Еавтоном.групп =

Теплота программы:

Q = TA

Module

Group – структура (R, g)

Auton – автом. (Res (Group), Rest (Module))

3) Оценка сложности: энергетические метрики

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

текстов программ или – при прогнозировании – по проектной документации.

Набор  мини  энергетических  метрик  (размерность всех, кроме первой, символ*бит) включает:

B – потенциал привнесённых ошибок кодированиия – вероятное среднее число  ошибок, допускаемых реализаторами программ (безразмерна);

 

E  – спецификационная энергия – мера сложности, исходящая из структуры программы и подсчёта для каждого из её мелкомасштабных  элементов («блоков»)  –  числа  формальных  параметров,

определяемых  по  числу  каналов  взаимодействия  с окружением при своём выполнении;

A – работа программирования – мера затратности  кодирования, исходящая  из  объёмов  исходных текстов и формальных параметров блоков;

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

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

Важнейшим условием расчёта указанных  метрик  является  идентификация  схемы программной системы  (СПС).  Основа  СПС  –  это  представление

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

длины N всех  программных  модулей,  измеренные в программных символах, обычно соответствуют лексемам данного языка программирования и их легко идентифицируемым сочетаниям;

словари  всех модулей – мощности множеств использованных программных символов;

количества p параметров  (всех  видов),  которыми снабжены блоки и модули;

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

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

4. CASE, ASIS. 

CASE- технология (Computer Aided Software Engineering — Компьютерное Автоматизированное Проектирование Программного обеспечения) является своеобразной "технологической оснасткой", позволяющей осуществить автоматизированное проектирование информационных технологий.

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

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

Выделяют две основные концепции компьютерного программного обеспечения системы CASE:

  •  простые и «прозрачные» методы упрощения разработки программного обеспечения и/или его технического обслуживания;
  •  Инженерный подход к разработке программного обеспечения и/или его технического обслуживания.

Типичными CASE инструментами являются:

  •  инструменты управления конфигурацией;
  •  инструменты моделирования данных;
  •  инструменты анализа и проектирования;
  •  инструменты преобразования моделей;
  •  инструменты редактирования программного кода;
  •  инструменты рефакторинга кода;
  •  генераторы кода;
  •  инструменты для построения UML-диаграмм.

ASIS (Ada Semantic Interface Specification, Спецификация Семантического Интерфейса к языку Ада)  -это новый стандарт Международной Организации по Стандартизации, область Информационных технологий, раздел Языков программирования, их окружений и программных интерфейсов к системам (ISO/IEC 15291:1999).

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

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

Область применения ASIS становится более понятной с учетом следующих его свойств:

ASIS - интерфейс "только для чтения" (read-only); иными словами, пользователь может получать информацию из ASIS-окружения, но не может изменять содержимое компонентов окружения.

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

ASIS является полной библиотекой запросов по отношению к синтактико-семантической информации языка Ада: ASIS предоставляет всю синтаксическую и базовую семантическую информацию о программах; любая семантическая зависимость, не доступная прямым вызовом некоторого запроса ASIS, вычислима некоторой комбинацией запросов.

Основные типы данных ASIS

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

Context (Контекст) - ограниченный приватный тип, служащий для задания множества анализируемых модулей из программного окружения.

Compilation_Unit (Единица Компиляции) - приватный тип, являющийся абстракцией элементов компиляции.

Unit Kinds (Типы Единиц Компиляции) - набор перечислимых типов, описывающих различные типы модулей компиляции.

Element (Элемент) - приватный тип, являющийся абстракцией сущностей внутри синтаксического дерева. Множество всех Элементов, соответствующих различным синтаксическим конструкциям данной Единицы Компиляции, является непосредственной абстракцией самого синтаксического дерева и называется деревом Элементов ASIS или просто деревом ASIS.

Element Kinds (Типы Элемента) - набор перечислимых типов, отображающих классификацию синтаксических конструктов языка Ада.

Program_Text (Текст программы) - тип данных, представляющий исходный текст программы; отображается на стандартный тип Wide_String.


1

2

3

4

5

6

группа

f(x)

g(x)

Модуль

М1

М2

N

M

- интерфейс

- реализация

Анализ

Проектирование

Реализация

Тестирование

Сопровождение

- use case

- управление         требован.

- прототип.

- DED

- ER

- IDEFO

- UML

- IDE (подсветка    синтаксиса, подсказки)

-  стандартное       кодирование

  -  метрики

  - рефактор

- автомат. тестирование

- анализ кода

«БЯ»


 

А также другие работы, которые могут Вас заинтересовать

19628. Технологія вирощування кролів. Утримання кролів 217.68 KB
  Урок 32. Технологія вирощування кролів. Утримання кролів 1 год. Мета уроку. Засвоєння знань про тваринництво як галузь сільськогосподарського виробництва способи утримання кролів особливості догляду за приміщеннями для кролів. Розвивати пам'ять. Виховувати інтерес
19629. Годівля кролів 28.91 KB
  2 Урок 33. Годівля кролів 1 год. Мета уроку: Засвоєння знань про годівлю кролів профілактику захворювань кролів; формування вмінь здійснювати догляд за кролями. Розвивати пам'ять спостережливість. Виховувати інтерес до сільськогосподарських тварин. Об’...
19630. Сферы применения маркетинга. Принципы маркетинга. Этапы развития маркетинга. Основные стратегии маркетинга 149.5 KB
  Занятие 1. Предмет и задачи курса. Сферы применения маркетинга. Принципы маркетинга. Этапы развития маркетинга. Основные стратегии маркетинга. Внешняя среда предприятия. Виды рынков. Сегмент рынка. Инструментарий маркетинга. Развитие предприятий на основе маркети
19631. Задачи управления маркетинговыми исследованиями и пути их решения 85 KB
  Занятие 2. Задачи управления маркетинговыми исследованиями и пути их решения. Формирование программы исследований. Основные группы методов маркетинговых исследований. Использование результатов маркетингового исследования для принятия маркетинговых решений М...
19632. Товарная политика. Задачи товарной политики и пути их решения. Полезность товара. Цикл жизни товара 64 KB
  Занятие 3. Товарная политика. Задачи товарной политики и пути их решения. Полезность товара. Цикл жизни товара. Качество и ассортимент продукции. Торговая марка и брэнд товара.. Позиционирование товара на рынке. Задачи товарной политики и пути их решения. Маркет...
19633. Ценовая политика. Задачи ценовой политики и пути их решения. Типовые подходы к определению цены товара 48 KB
  Занятие 4. Ценовая политика. Задачи ценовой политики и пути их решения. Типовые подходы к определению цены товара. Система скидок и надбавок как инструмент согласования интересов предприятия и потребителя. Задачи ценовой политики и пути их решения. Цена – денежно
19634. Коммуникационная политика. Задачи коммуникационной политики и пути их решения. Реклама и рекламная деятельность 83.5 KB
  Занятие 5. Коммуникационная политика. Задачи коммуникационной политики и пути их решения. Реклама и рекламная деятельность. Работа с общественностью по формированию положительного имиджа. Персональные продажи как эффективный метод продвижения товара. Задачи ко...
19635. Сбытовая политика. Задачи сбытовой политики и пути их решения. Продвижение и распространение продукции 95.5 KB
  Занятие 6. Сбытовая политика. Задачи сбытовой политики и пути их решения. Продвижение и распространение продукции. Основные функции решаемые системой сбыта. Задачи сбытовой политики и пути их решения. Главной задачей сбытовой политики предприятия является продви...
19636. Организация службы маркетинга на предприятии. Информационные технологии в маркетинге 58.5 KB
  Занятие 7. Организация службы маркетинга на предприятии. Информационные технологии в маркетинге. 1. Организация службы маркетинга на предприятии. Задача управления маркетингом заключается в воздействии на уровень время и характер спроса таким образом чтобы про...