- •1. Жизненный цикл программной системы.
- •2. Классический подход к созданию программных систем.
- •3. Понятия связности модулей и сцепления модулей.
- •4. Структурное программирование.
- •Структурное тестирование программного обеспечения
- •1. Связь процессов тестирования и процессов проектирования.
- •2. Уровни тестирования и виды тестирования.
- •3. Стратегия тестирования.
- •4. Тестирование программного модуля.
- •5. Восходящее и нисходящее тестирование.
- •6. Методы тестирования: модифицированный нисходящий, монолитный, сандвич, модифицированный сандвич.
- •7. Системное тестирование: метод функциональных диаграмм.
- •Объектно-ориентированный подход к разработке по
- •1. Абстрагирование и инкапсуляция
- •2. Модульность программных систем
- •3. Виды иерархий в программных системах.
- •4. Понятие объекта. Состояние, поведение и индивидуальность объекта.
- •5. Отношение между объектами: использование, включение.
- •6. Отношение простого наследования классов.
- •7. Добавление, замещение и уточнение методов класса при наследовании.
- •8. Отношение ассоциации между классами, включая агрегацию.
- •9. Отношение зависимости между классами, отношение реализации.
- •Шаблоны проектирования
- •1. Шаблон «Одиночка» Singleton
- •2. Шаблон «Фабричный метод» Factory Method
- •3. Шаблон «Декоратор» Decorator
- •4. Шаблон «Стратегии» Strategy
- •5. Шаблон «Компоновщик» Composite.
- •6. Шаблон «Наблюдатель» Observer
- •7. Архитектурные шаблоны (парадигмы).
- •Унифицированный процесс разработки по (rup)
- •1. Основные черты. Фазы и основные потоки работ.
- •2. Документ «Видения». Модель и словарь предметной области.
- •3. Функциональные и нефункциональные требования к системе. Варианты использования системы.
- •4. Прецеденты и отношения между прецедентами.
- •5. Модель анализа и классы анализа.
- •6. Архитектурное представление.
2. Модульность программных систем
Разделение программы на модули до некоторой степени позволяет уменьшить ее сложность. Однако гораздо важнее тот факт, что внутри модульной программы создаются множества хорошо определенных и документированных интерфейсов. Эти интерфейсы неоценимы для исчерпывающего понимания программы в целом. Классы и объекты составляют логическую структуру системы, они помещаются в модули, образующие физическую структуру системы. Это свойство становится особенно полезным, когда система состоит из многих сотен классов.
Модульность - это разделение программы на фрагменты, которые компилируются по отдельности, но могут устанавливать связи с другими модулями. Связи между модулями - это их представления друг о друге.
В C++ модулями являются раздельно компилируемые файлы. Для C++ традиционным является помещение интерфейсной части модулей в отдельные файлы с расширением .h (так называемые файлы-заголовки). Реализация, то есть текст модуля, хранится в файлах с расширением .сpp. Связь между файлами объявляется директивой макропроцессора #include.
Для небольших задач допустимо описание всех классов и объектов в одном модуле. Однако для большинства программ лучшим решением будет сгруппировать в отдельный модуль логически связанные классы и объекты, оставив открытыми те элементы, которые необходимо видеть другим модулям.
Конечной целью декомпозиции программы на модули является снижение затрат на программирование за счет независимой разработки и тестирования. Структура модуля должна быть достаточно простой для восприятия; реализация каждого модуля не должна зависеть от реализации других модулей; должны быть приняты меры для облегчения процесса внесения изменений там, где они наиболее вероятны. На практике перекомпиляция тела модуля не является трудоемкой операцией: заново компилируется только данный модуль, и программа перекомпонуется. Перекомпиляция интерфейсной части модуля, напротив, более трудоемка. В строго типизированных языках приходится перекомпилировать интерфейс и тело самого измененного модуля, затем все модули, связанные с данным, модули, связанные с ними, и так далее по цепочке. В итоге для очень больших программ могут потребоваться многие часы на перекомпиляцию, что явно нежелательно. Постепенный перенос описаний из реализации в интерфейсную часть гораздо менее опасен, чем "вычищение" избыточного интерфейсного кода.
Поэтому следует стремиться построить модули так, чтобы объединить логически связанные абстракции и минимизировать взаимные связи между модулями.
Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.
Таким образом, принципы абстрагирования, инкапсуляции и модульности являются взаимодополняющими. Объект логически определяет границы определенной абстракции, а инкапсуляция и модульность делают их физически незыблемыми.
Выводы:
Модульность - разделение программного материала на фрагменты с целью уменьшения его сложности.
Модуль состоит: реализация, интерфейс. Изнутри модуля можем видеть только интерфейсную часть другого модуля.
Отношение между модулями - отношение компиляционной зависимости, отношение импорта-экспорта.