Лекция № 2

тема: « ОСНОВНЫЕ ПОНЯТИЯ И ПОЛОЖЕНИЯ ТЕХНОЛОГИИ

РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ»

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

ПС современных ИС являются типичными сложными системами со

всеми их особенностями (наличие общей задачи и единой цели

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

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

относятся [2, 5]:

1) проблемы рационального структурного построения ПС,

включающие:

– оптимизацию структуры ПС по критерию максимального





использования ресурсов ЭВМ;

– контроль вычислительного процесса и обеспечение надёжности ПС;

– обеспечение простой корректировки ПС и др.;

2) проблемы технологии разработки ПС, включающие:

– разработку моделей алгоритмов и др. компонентов ИС;

– автоматизацию программирования на основе унификации типовых

компонент программ;

– обеспечение отладки и испытаний программ;

– автоматизацию изготовления документации и др.;

3) проблемы стандартизации и унификации ПС, включающие:

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

передаче управления и по обменной информации;





– унификацию правил и методов построения ПС, общих правил

иерархии и взаимодействия программ и методов организации

вычислительного процесса;

– стандартизацию методов и требований к обеспечению и измерению

качества ПС;

– стандартизацию языков программирования.

2. Этапы жизненного цикла программных средств

По длительности ЖЦ ПС можно разделить на 2 класса [5]:

а) с малым, б) большим временем жизни.

ПС с малым временем ЖЦ (до 3 лет) и объёмом 1 – 10 тысяч команд

разрабатываются обычно в НИИ и вузах одним специалистом.

ПС с большим временем ЖЦ (10 – 20 лет, из которых 70 – 90 %





приходится на эксплуатацию и сопровождение), с объёмом 10 – 1000

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

создаются на основе промышленного регламентированного проек-

тирования. ЖЦ таких программ включает в себя этапы [2]: системный

анализ, проектирование, эксплуатацию, сопровождение. Наиболее

специфическим, трудноформализуемым и тесно связанным с

функциональным назначением является этап системного анализа, на

котором формируются назначение и основные показатели качества ПС.

Этапы проектирования, эксплуатации и сопровождения сильно

различаются целями, задачами, методами и средствами. Процесс

эксплуатации идёт параллельно и независимо от этапа сопровождения и

сводится к исполнению программ на ЭВМ и обеспечению достоверности и

надёжности результатов.

Этап сопровождения состоит в эксплуатационном обслуживании,

развитии функциональных возможностей и характеристик ПС, а также в

тиражировании ПС и переносе их на различные типы ЭВМ.

Наиболее трудоёмким является этап проектирования, требующий

методической, технологической, инструментальной и организационной

поддержки [2, 5].

3. Виды поддержки и стадии этапа проектирования

Методическая поддержка включает в себя комплекс стандартов,

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

конкретизирующих языки проектирования, правила использования

символов, структурного построения и другие методические основы

процесса создания программ.

Технологическая поддержка является детализацией документов

методической поддержки, регламентирующей конкретную технологию

обеспечения ЖЦ программ. Эти документы определяют допустимую

трудоёмкость и длительность каждого этапа и обеспечивают нужное

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

Процесс разработки ПС делится на стадии [5]: техническое проектирование и рабочее проектирование. Первая стадия включает этапы: структурное проектирование, подготовка технических средств, разработка программ.

Вторая стадия включает этапы: завершение разработки программ, отладка программ в статике, комплексная динамическая отладка программ, выпуск машинных носителей, испытания ПС. Все виды работ и задач, выполняемых на этих этапах, сгруппированы для оценки трудоёмкости разработки ПС в 5 групп [2]: анализ разработки, проектирование, программирование, тестирование, внедрение. Подробное рассмотрение состава и содержания работ в каждой группе приведено в соответствующей литературе [7], использованной при подготовке методических указаний к проведению лабораторных работ (подразделы 6.1, 6.2). Важное значение для успешного их проведения имеют результаты статического анализа.

4. Основные понятия и определения статического анализа

программных средств

Статический анализ (СА) – это процесс анализа исходного текста

программы без её выполнения на ЭВМ [12]. СА программ проводится:

– для проверки модульной структуры программного средства, а

также логической структуры отдельных модулей и сравнения этих структур с приведенными в программной документации; – подготовки исходных данных для проведения динамического анализа ПС и разработки плана тестирования ПС;

– оценки конструктивных характеристик программы, степени

простоты модификации и сопровождения программы;

– определения наличия несовершенства в программе,

неиспользуемых участков программы, лишних переменных;

– оценки текстовой сложности программы, затрат на ее разработку и освоение;

– экспертизы идентичности программ при установлении авторства и

разрешении правовых споров;

– определения количественных характеристик при оценке уровня

качества программы.

Статический анализ начинается со стадии проектирования

программы (укрупненный анализ) и продолжается на всех последующих

фазах жизненного цикла программного средства.

Статический анализ программного средства предусматривает

получение следующих характеристик (графических и метрических):

модульная структура ПС; логическая структура отдельного программного модуля; характеристика текста программы.

Модульная структура анализируемого ПС представляется в виде

графа вызовов; списка путей вызовов; матрицы вызовов и достижимости;

точек вызовов; метрик иерархии вызовов.

Логическая структура отдельного программного модуля

представляется в виде графа управления; путей тестирования; метрик

структуры управления.

Характеристики текста программ включают в себя: статистические

данные о комментированности программы и текстовые метрики Холстеда.

Граф вызовов – это ориентированный граф, в котором вершины – модули

ПС, а рёбра ориентированы от вызывающего модуля к вызываемому.

Граф управления −это ориентированный граф, вершинами которого

являются логические блоки, а направленные ребра ориентированы в

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

Путь тестирования – это маршрут в графе управления программного

модуля, начальная вершина которого является входной вершиной графа, а

конечная вершина − выходной вершиной графа. Точка вызовов – это местоположение вызова программной компоненты (модуля), задаваемое номером строки и столбца расположения оператора вызова. Кроме этого СА предусматривает определение ряда количественных характеристик, таких как иерархическая и структурная сложность, тестируемость и др.

Иерархическая сложность:

I = N / L,

где N – количество вершин в графе вызовов модулей; L – количество уровней.

Иерархическая сложность характеризует среднюю ширину уровня в

графе вызовов, т.е. количество проектных решений, принимаемых на

отдельном шаге разработки программы.

Структурная сложность:

S = D / N,

где D – количество ребер в графе вызовов модулей; N – количество вершин.

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