ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 22.03.2025
Просмотров: 1262
Скачиваний: 1
СОДЕРЖАНИЕ
1.Основные понятия и подходы к тп
2. Приемы обеспечения технологичности программных продуктов
3. Определение требований к по и исходных данных для его проектирования
4. Анализ требований и определение спецификации по при структурном подходе
5. Проектирование программного обеспечения при структурном подходе
6. Анализ требований и определение спецификаций программного обеспечения при объектном подходе
7. Проектирование по при объектном подходе
8.1. Виды контроля качества разрабатываемого по.
8.2. Формирование тестовых наборов
8.4. Функциональное тестирование
8.5. Тестирования модулей и комплексное тестирование
9. Отладка программного обеспечения
9.2. Методы отладки программного обеспечения
Сцепление модулей
Сцепление является мерой взаимозависимости модулей, которая определяет, насколько хорошо модули отделены друг от друга. Модули независимы, если каждый из них не содержит о другом никакой информации.
5 типов сцепления:
по данным – модули обмениваются данными, представленными скалярными значениями. При небольшом количестве передаваемых параметров этот тип обеспечивает наилучшие технологические характеристики ПО.
сцепление по образцу – модули обмениваются данными, объединенными в структуры. Здесь характеристики хуже, чем в первом случае, так как уменьшается прозрачность между модулями.
сцепление по управлению – один модуль посылает другому некоторый информационный объект (флаг), предназначенный для управления внутренней логикой модуля. Таким способом часто выполняют настройку режимов работы ПО. Это снижает наглядность взаимодействия модулей. Поэтому характеристики технологичности здесь хуже.
Function min_max (a, b: integer; f: boolean ): integer;
begin
if (a>b) and (f) then min_max:=a
else min_max:=b
end;
4) сцепление по общей области данных предполагает, что модули работают с общей областью данных. Этот тип является недопустимым, так как программы сложны для понимания. Ошибка одного модуля, приводящая к изменению общих данных, может проявиться при выполнении другого модуля. При ссылке к данным в общей области модули используют конкретные имена, что уменьшает гибкость разрабатываемого ПО. Например, функция maxиспользует глобальный массивa, но сцеплена с основной программой по общей области. Подпрограммы “с памятью”, действие которых зависит от истории вызова используемого сцепления по общей области, что делает их работу в общем случае непредсказуемой. Этот вариант использует статические переменныеCиC++.
5) сцепление по содержимому. Один модуль содержит обращение к внутренним компонентам другого (передает управление внутрь, читает и/или изменяет внутренние данные или сами коды, что противоречит блочно-иерархическому подходу). Отдельный модуль в этом случае уже не является блоком. Его содержимое должно учитываться в процессе разработки другого модуля. Современные универсальные языки программирования этого типа сцепления в явном виде их поддерживают, но для языков низкого уровня этот вид сцепления остается возможным.
Характеристики различных типов сцепления по экспертным оценкам
|
Тип сцепления |
Балл |
Устойчивость к ошибкам других модулей |
Наглядность (понятность) |
Возможность изменения |
Вероятность повторного использования |
|
1) по данным |
1 |
хорошая* |
хорошая |
хорошая |
большая |
|
2) по образцу |
3 |
средняя |
хорошая* |
средняя |
средняя |
|
3) по управлению |
4 |
средняя |
плохая |
плохая |
малая |
|
4) по общей области |
6 |
плохая |
плохая |
средняя |
малая |
|
5) по содержанию |
10 |
плохая |
плохая |
плохая |
малая |
*- зависит от количества параметров интерфейса.
Допустимыми считаются первые три типа сцепления. Обычно модули сцепляются между собой несколькими способами, учитывая это, качество ПО принято определять по типу сцепления с худшими характеристиками. В некоторых случаях сцепление модуля можно уменьшить, удалив необязательные связи и структурировав необходимые связи. Пример – ООП, в котором вместо большого количества параметров метод неявно получает адрес области (структуры), в которой расположены поля объекта и явно-дополнительные параметры. В результате модули оказываются сцепленными по образцу.
Связность модулей
Связность– это мера прочности соединения функциональных и информационных объектов внутри одного модуля. Если сцепление характеризует качество отделения модулей, то связность характеризует степень взаимосвязи элементов, реализуемых одним модулем.
Размещение сильно связанных элементов в одном модуле уменьшает межмодульные связи, то есть взаимное влияние модулей. Помещение сильно связанных элементов в разные модули усиливает межмодульные связи и усложняет понимание их взаимодействия. Объединение слабо связанных элементов также уменьшает технологичность модуля. Виды связности (в порядке убывания уровня):
Функциональная
Последовательная
Информационная (коммуникативная)
Процедурная
Временная
Логическая
Случайная
1). Все объекты модуля предназначены для выполнения одной функции: операции, объединяемые для выполнения одной функции, или данные, связанные с одной функцией.
Рис.2.1. Связность одной функции.
Модуль, элементы которого связаны функционально, имеют четко определенную цель, при его вызове выполняется одна задача. Связность такого модуля максимальна, хорошие технологические качества: простота тестирования, модификации. Поэтому следует избегать неструктурированного распределения функций между модулями – библиотеками ресурсов.
2). Выход одной функции служит исходными данными для другой функции.
Рис.2.2.
Обычно такой модуль имеет одну точку входа, то есть реализует подпрограмму, реализующую две функции. Считают, что данные, используемые функциями, также связаны последовательно. Модуль можно разбить на два или более модуля, как с последовательной, так и с функциональной связью. Так как модуль выполняет несколько функций, его технологичность хуже.
3). Информационно связанным считают функции, обрабатывающие одни и те же данные. При использовании структурных языков программирования раздельное выполнение функций можно осуществить, если каждая функция выполняется своей подпрограммой.
Рис.2.3.
Имеет неплохие показатели технологичности, так как все функции, работающие с некоторыми данными, собраны в одно место, что при изменении формата данных изменять один модуль. Информационно связанными считаются данные, которые обрабатываются одной функцией.
4). Процедурно связаны функции или данные, которые являются частями одного процесса.
Рис.2.4.
Обычно такие модули получают, если в модули объединены функции альтернативных частей программы. Отдельные элементы модуля связаны слабо, то есть реализуемые ими действия связаны общим процессом. Технологичность ниже.
5). Временная связность функций подразумевает, что эти функции выполняются параллельно или в течение некоторого времени.
Рис.2.5.
Временная связность данных означает, что они используются в некотором временном интервале. Например, временную связность имеют функции, выполняемые при инициализации некоторого процесса. Особенность временной связности в том, что действия, реализуемые такими функциями, обычно могут выполняться в любом порядке. Содержание такого модуля имеет тенденцию меняться: в него могут включаться новые и/или исключаться старые действия. Большая вероятность модификации функций уменьшает показатели технологичности.
6). Логическая связность базируется на объединении данных или функций в одну логическую группу.
Рис.2.6.
Пример – функции обработки текстовой информации или данные одного и того же типа. Модуль с логической связностью функций часто реализует альтернативные операции.
7). Если связь между элементами мала или отсутствует, то они имеют случайную связность. Такие модули имеют самый низкий показатель технологичности.
|
Вид связности |
Сцепление (балл) |
Наглядность (понятность) |
Возможность изменения |
Сопровождаемость |
|
1). Функциональная |
10 |
Хорошая |
Хорошая |
Хорошая |
|
2). Последовательная |
9 |
Хорошая |
Хорошая |
Хорошая |
|
3). Информационная |
8 |
Средняя |
Средняя |
Средняя |
|
4). Процедурная |
5 |
Средняя |
Средняя |
Плохая |
|
5). Временная |
3 |
Средняя |
Средняя |
Плохая |
|
6). Логическая |
1 |
Плохая |
Плохая |
Плохая |
|
7). Случайная |
0 |
Плохая |
Плохая |
Плохая |
Обычно при хорошо продуманной декомпозиции модули верхних уровней иерархии имеют функциональную или последовательную связность функций и данных. Для модулей обслуживания данных характерна информационная связность функций. Данные таких модулей могут быть связаны по-разному. Модули, содержащие описание классов при объектно-ориентированном подходе, характеризуются информационной связностью методов и функциональной связностью данных. Получение в процессе декомпозиции модулей с другими типами связности обычно означает недостаточно продуманное проектирование. Исключением являются библиотеки ресурсов.
Библиотеки ресурсов
Различают библиотеки программ и библиотеки классов.
Библиотеки подпрограмм реализуют функции близкие по назначению. Связность подпрограмм между собой в такой библиотеке логическая, а связность самих подпрограмм – функциональная.
Библиотеки классов реализуют близкие по назначению классы. Связность элементов класса информационная, а связность классов между собой может быть функциональной для родственных классов или логической для остальных. Для улучшения технологических характеристик библиотек ресурсов используется разделение тела модуля на интерфейсную часть и область реализации.
2.3. Нисходящая и восходящая разработка ПО
В литературе встречается ещё один подход – «расширение» ядра. Он предполагает, что в первую очередь проектируют и разрабатывают ядро ПО, например структуры данных и процедуры, связанные с ними. Затем ядро наращивают, комбинируя нисходящий и восходящий методы. На практике данный подход в зависимости от уровня ядра сводится к нисходящему и восходящему подходу.
Восходящий подход. Сначала проектируют и реализуют компоненты нижнего уровня, затем следующего и т.д. По мере завершения тестирования и отладки компонентов осуществляют их сборку. Компоненты нижнего уровня часто помещают в библиотеки компонентов. Для тестирования и отладки компонентов проектируют и реализуют специальные тестирующие программы. Недостатки:
увеличение вероятности несогласованности компонентов вследствие неполноты спецификации;
наличие издержек на проектирование и реализацию тестирующих программ;
позднее проектирование интерфейса, следовательно невозможность продемонстрировать его заказчику.
Исторически восходящий подход появился раньше, что было связано с особенностью мышления программистов. При промышленном изготовлении ПО восходящий подход практически не используется.