Лекции по курсу «Метрология и качество программного обеспечения» Лекция 6. Архитектура программных

Лекции по курсу
«Метрология и качество программного
обеспечения»
Лекция 6. Архитектура программных
средств. Разработка структуры
программ и модульное
программирование
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Архитектура программных средств
Определение и задачи разработки архитектуры программных средств
Архитектура ПС – это его строение как оно видно извне его, то есть
представление ПС как системы, состоящей из совокупности
взаимодействующих подсистем.
Основное назначение разработки архитектуры – борьба со
сложностью в программном средстве.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Архитектура программных средств
Определение и задачи разработки архитектуры программных средств
(продолжение)
Основные задачи, решаемые при разработке архитектуры:
- выделение программных подсистем и отображение на них внешних
функций ПС;
- определение способов взаимодействия между выделенными
программными подсистемами.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные классы архитектур
программных средств
Перечень основных классов архитектур программных средств
1. Цельная программа;
2. Комплекс автономно выполняемых программ;
3. Слоистая программная система;
4. Коллектив параллельно выполняемых программ.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные классы архитектур
программных средств
Класс архитектуры – цельная программа
Цельная программа представляет собой вырожденный случай
архитектуры ПС – в состав ПС входит только одна программа.
Такую архитектуру выбирают в том случае, когда программное
средство должно выполнять одну ярко выраженную функцию и
её реализация не представляется слишком сложной.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные классы архитектур
программных средств
Класс архитектуры – комплекс автономно выполняемых программ
Комплекс автономно выполняемых программ состоит из набора
программ, такого что:
-
любая из программ может быть активизирована (запущена)
пользователем;
-
при выполнении активизированной программы другие программы
не могут быть активизированы, пока не закончит работу
запущенная программа;
-
все программы набора применяются к одной и той же
информационной среде, но между собой не взаимодействуют.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные классы архитектур
программных средств
Класс архитектуры – слоистая программная система
Слоистая программная система состоит из некоторой упорядоченной
совокупности программных подсистем, называемых слоями
(layer), такой, что:
-
на каждом слое ничего неизвестно о существовании более
высоких слоёв;
-
каждый слой может взаимодействовать с непосредственно
предшествующим (более низким) слоем через заранее
определённый интерфейс;
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные классы архитектур
программных средств
Класс архитектуры – слоистая программная система (пример)
Прикладные программы
3: Управление входными и выходными потоками данных
2: Обеспечение связи с консолью оператора
1:
Управление памятью
0:
Диспетчеризация и синхронизация процессов
Компьютер
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные классы архитектур
программных средств
Класс архитектуры – коллектив параллельно действующих программ
Коллектив параллельно действующих программ представляет собой
набор программ, способных взаимодействовать между собой,
находясь одновременно в стадии выполнения.
Взаимодействие между программами производится путём передачи
ими друг другу некоторых сообщений.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Архитектурные функции
Понятие об архитектурных функциях
В ряде случаев для обеспечения взаимодействия между
программными подсистемами может потребоваться создание
дополнительных программных компонент.
Такие программные компоненты реализуют не внешние функции ПС,
а функции, возникшие в результате разработки архитектуры
этого ПС. Такие функции называются архитектурными.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Контроль архитектуры ПС
Методы контроля архитектуры ПС
Для контроля архитектуры используются:
1. Смежный контроль архитектуры
- сверху (разработчиками внешнего описания);
- снизу (разработчиками программных подсистем);
2. Ручная имитация
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные понятия и цели модульного
программирования
Понятие о модульном программировании
Программный модуль – это любой фрагмент описания процесса,
оформляемый как самостоятельный программный продукт.
Каждый программный модуль программируется, компилируется и
отлаживается отдельно от других модулей программы, и, тем
самым, физически разделён с другими модулями программы.
В современных языках программирования программный модуль
может быть интерпретирован собственно модулем, процедурой
или функцией.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные характеристики
программного модуля
Перечень основных характеристик программного модуля
1. Размер модуля;
2. Прочность модуля;
3. Сцепление с другими модулями;
4. Рутинность модуля (независимость от предыстории обращений);
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные характеристики
программного модуля
Характеристика – размер модуля
Размер модуля определяется числом содержащихся в нём
операторов или строк. Модуль не должен быть слишком
маленьким или слишком большим. Рекомендуемый размер
модуля – от нескольких десятков до нескольких сотен
операторов.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные характеристики
программного модуля
Характеристика – прочность модуля
Прочность модуля – это мера его внутренних связей. Чем выше
прочность модуля, тем больше связей по отношению к внешней
программе он может спрятать и тем больший вклад в упрощение
программы внести.
Классы прочности модулей:
-
прочный по совпадению;
-
функционально прочный модуль;
-
информационно прочный модуль.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные характеристики
программного модуля
Характеристика – сцепление модуля
Сцепление модуля – это мера его зависимости по данным от других
модулей. Характеризуется способом передачи данных.
Виды сцепления модулей:
-
сцепление по содержимому;
-
сцепление по общей области;
-
параметрическое сцепление.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные характеристики
программного модуля
Характеристика – рутинность модуля
Рутинность модуля – это его независимость от предыстории
обращений к нему. Модуль называется рутинным, если результат
обращения к нему зависит только от значений его параметров. В
противном случае модуль называется зависимым от
предыстории.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Основные характеристики
программного модуля
Рекомендации по использованию рутинных модулей
1. Всегда следует использовать рутинный модуль, если это не
приводит к плохим сцеплениям модулей.
2. Зависящие от предыстории модули следует использовать только
в случае, когда это необходимо для обеспечения
параметрического сцепления;
3. В спецификации зависящего от предыстории модуля должна
быть чётко сформулирована эта зависимость.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Методы разработки структуры
программы
Два основных метода разработки структуры программы
1. Метод восходящей разработки
2. Метод нисходящей разработки
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Методы разработки структуры
программы
Метод восходящей разработки - этапы
1. Строится модульная структура программы в виде дерева;
2. Поочерёдно программируются модули программы, начиная с
модулей самого нижнего уровня;
3. Производится поочерёдная отладка и тестирование модулей в
том же порядке, как и их программирование.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Методы разработки структуры
программы
Метод нисходящей разработки - этапы
1. Строится модульная структура программы в виде дерева;
2. Поочерёдно программируются модули программы, начиная с
модулей самого верхнего (головного) уровня;
3. Производится поочерёдная отладка и тестирование модулей в
том же порядке, как и их программирование. Несуществующие
модули более низкого уровня заменяются имитаторами
(заглушками).
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС
Контроль структуры программы
Три метода контроля структуры программы
1. Статический контроль;
2. Смежный контроль (сверху и снизу);
3. Сквозной контроль.
© В.М. Гриняк, доц. каф. ИСКТ ВГУЭС