- •Технология программирования. Качество программных систем.
- •Аспекты качества оценки программных систем.
- •Стадии разработки программного обеспечения.
- •Внедрение:
- •Разработка спецификаций.
- •Разработка спецификаций методом структурного анализа.
- •Разработка спецификаций оперативно-графическим методом (hipo).
- •Документирование программного обеспечения.
- •Проектирование систем.
- •Определение основных компонентов системы.
- •Определение потоков данных.
- •Определение процессов.
- •Методы разработки данных.
- •Графические диаграммы (граф-диаграммы)
- •Диаграммы Варнье-Орра.
- •Функциональные схемы.
- •Проектирование программ.
- •Группы методов проектирования программ:
- •Метод нисходящего проектирования.
- •Пошаговое уточнение.
- •Модульная структура программ.
- •Монолитно-модульная структура.
- •Последовательно-модульная структура.
- •Модульно-иерархическая структура.
- •Модульно-хаотическая структура.
- •Технологический цикл конструирования программной системы (пс): три процесса.
- •Модель анализа:
- •Этап проектирования
- •Этап кодирования
- •Этап проектирования
- •Проверенная и объединённая пс
- •Особенности этапа проектирования.
- •Предварительное
- •Детальное
- •Интерфейсное
- •Структурирование систем.
- •Управление
- •Моделирование управления.
- •Модель централизованного управления.
- •Главная
- •Обработчик событий и
- •Прерывания
- •Обработчик
- •Процесс
- •Декомпозиция подсистем на модули. Модульность.
- •Характеристики модуля.
- •Последовательная связность.
- •Коммуникативная связность.
- •Модуль отчёт о средней зарплате
- •Процедурная связность.
- •Модуль вычисления средних значений
- •Модуль вычисления средних значений
- •Временная связность.
- •Модуль инициализировать систему
- •Логическая связность.
- •По совпадению.
- •Сцепление модулей.
- •Сложность программной системы.
- •Программная документация.
- •Средства проектирования прикладных программ.
- •Графическое построение схем алгоритмов и программ.
- •Разработка схем алгоритмов и программ с использованием конкретного языка программирования.
- •Использование специальных языков проектирования программ, псевдокодов.
- •Реализация программ.
- •Программирование на языках высокого уровня:
- •Программирование с защитой от ошибок.
- •Структурное программирование.
- •Программирование в стандартизированном стиле.
- •Основные принципы стандартизации стиля программирования:
- •Правила размещения фрагментов исходного текста.
- •Правила составления комментариев.
- •Основное правило составления пояснительных комментариев.
- •Правило выбора имён.
- •Правило обеспечения наглядности логической структуры.
- •Нисходящее программирование.
- •Методы проверки программ:
- •Тестирование программного обеспечения.
- •Тестирование элементов.
- •Тестирование интеграций.
- •Нисходящее тестирование интеграций.
- •Возможные шаги процесса нисходящей интеграции:
- •Восходящие тестирования интеграций.
- •Сравнение нисходящего и восходящего тестирования.
- •Тестирование правильности.
- •Системное тестирование.
- •Основные типы системных тестов.
- •Тестирование восстановления.
- •Тестирование безопасности.
- •Стрессовое тестирование.
- •Тестирование производительности.
- •Аксиомы тестирования.
- •Отладка.
- •Общая схема сопровождения по.
Сцепление модулей.
Это мера взаимозависимости модулей по данным; это внешняя характеристика, которую желательно уменьшить. Количественно сцепление измеряется степенью сцепления.
Типы сцепления:
Сцепление по данным СЦ=1 (сила сцепления)
М одуль А вызывает модуль В.
Все входные и выходные параметры вызываемого модуля – простые элементы данных.
Сцепление по образцу СЦ=3
В качестве параметров используются структуры данных.
Сцепление по управлению. СЦ=4
Модуль А явно управляет функциони-рованием модуля В (с помощью флагов или переключателей), посылая ему управ-ляющие данные.
Сцепление по внешним ссылкам. СЦ=5
Модули А и В ссылаются на один и тот же глобальный элемент данных.
Сцепление по общей области. СЦ=7
Модули разделяют одну и ту же глобальную структуру данных.
Сцепление по содержанию. СЦ=9
Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом (Sin и Cos сдвинуты на 90).
Сложность программной системы.
По Холстеду сложность программной системы оценивается мерой длины модуля.
N=n1*log (n1) + n2*log (n2)
N – Длина модуля
n1 – Число различных операторов
n2 – Число различных операндов
Вторая характеристика – объём модуля.
V – Количество символов для записи операторов и операндов текста модуля.
V=N*log (n1+n2)
Том Мак Кейб в качестве характеристики сложности программы предложил использовать топологию внутренних связей.Для этого была разработана метрика
циклологической сложности.
V(G)=E-N+2
E – Количество дуг
N – Количество вершин в управляющем графе программной системы
Таким образом при комплексной оценке сложности программной системы необходимо рассматривать:
Меру сложности модулей;
Меру сложности внешних связей;
Меру сложности внутренних связей.
На основе полных коэффициентов функциональных модулей вычисляется метрика общей сложности структуры.
S= *(Fan_in(i)+Fan_out(i)) (*)
length(i) – Оценка размера i-ого модуля
Fan_in(i) – Коэффициент объединения по входу(Количество управляющих
i-ым модулем модулей)
Fan_out(i) – Коэффициент разветвления по выходу(Количество модулей,ко-торыми прямо управляет i-ый модуль)
Характеристики йерархической структуры программной системы.
m
Высота
Depth
n
F an_in(n)=2
Ширина
F an_out(m)=3
Width
Рассмотрим основные характеристики йерархической структуры,представ-
ленной на рисунке.
Первыми характеристиками являются количество вершин (модулей) и коли-чество рёбер (связей между модулями).К ним добавляются две глобальные харак-теристики – высота и ширина:
Высота – количество уровней управления;
Ширина – максимальное из количеств модулей,размещённых на уров-нях управления.
В нашем примере высота = 3,ширина = 3.
Локальными характеристиками модулей структуры являются коэффициент
объединения по входу и коэффициент разветвления по выходу (Fan_in(i) и Fan_out(i) ).
В примере для модуля n: Fan_in(n)=2 ;для модуля m: Fan_out(m)=3.
Возникает вопрос:как оценить качество структуры? Из практики проекти-рования известно,что лучшее решение обеспечивается йерархической структурой
в виде дерева.
Степень отличия реальной проектной структуры от дерева характеризуется невязкой структуры(Nev).
Значение невязки лежит в диапазоне от 0 до 1.Если Nev = 0,то проектная структура является деревом,если Nev = 1,то проектная структура – полный граф.
Ясно,что невязка даёт грубую оценку структуры.Для увеличения точности оценки следует применить характеристики связности и сцепления.
Хорошая структура должна иметь низкое сцепление и высокую связность.
Л.Констентайн и Э.Йордан (1979) предложили оценивать структуру с помо-щью коэффициентов Fan_in(i) и Fan_out(i) модулей.
Большое значение Fan_in(i) – свидетельство высокого сцепления,так как является мерой зависимости модуля.Большое значение Fan_out(i) говорит о высо-кой сложности вызывающего модуля.Причиной является то,что для координации подчинённых модулей требуется сложная логика управления.
Основной недостаток коэффициентов Fan_in(i) и Fan_out(i) состоит в игно-рировании веса связи.Здесь рассматриваются только управляющие потоки (вызо-вы модулей).В то же время информационные потоки,нагружающие рёбра структу-ры,могут существенно изменяться,поэтому нужна мера,которая учитывает не только количество рёбер,но и количество информации,проходящей через них.
С.Генри и Д.Кафура (1981) ввели информационные коэффициенты ifan_in(i) и ifan_out(j).Они учитывают количество элементов и структур данных,из которых i-й модуль берёт информацию и которые обновляются j-м модулем соответствен-но.
Информационные коэффициенты суммируются со структурными коэффи-циентами sfan_in(i) и sfan_out(j),которые учитывают только вызовы модулей.
В результате формируются полные значения коэффициентов:
Fan_in(i)= sfan_in(i)+ifan_in(i),
Fan_out(j)=sfan_out(j)+ifan_out(j).
На основе полных коэффициентов модулей вычисляется метрика общей сложности структуры: Формула (*).