
- •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. Архитектурное представление.
8. Отношение ассоциации между классами, включая агрегацию.
Ассоциация (association) – описание связей между экземплярами классов.
Ассоциация — двусторонняя ссылка, при каждом изменении ассоциации изменяются атрибуты обоих объектов. Говорят о множественности ассоциации, т.е. о количестве объектов, участвующих в ней.
Обозначается сплошной линией со стрелкой или без нее и с дополнительными символами, которые характеризуют специальные свойства ассоциации:
Имя ассоциации - необязательный элемент ее обозначения. Однако если оно задано, то записывается с заглавной буквы.
Множественность или кратность ассоциации – отношение 1-1, 1-n, n-m.
Ассоциация может быть бинарной – связывает в точности два различных класса и может быть ненаправленным (симметричным) или направленным отношением. Частный случай бинарной ассоциации - рефлексивная ассоциация, которая связывает класс с самим собой. Ненаправленная бинарная ассоциация изображается линией без стрелки. Для нее на диаграмме может быть указан порядок чтения классов с использованием значка в форме треугольника рядом с именем данной ассоциации.
Направленная бинарная ассоциация изображается сплошной линией с простой стрелкой на одной из ее концевых точек. Направление этой стрелки указывает на то, какой класс является первым, а какой - вторым.
Пример бинарной направленной ассоциации
Помимо бинарной ассоции также существуют n-арные, где n – количество классов.
Агрегация (aggregation) - специальная форма ассоциации, которая служит для представления отношения типа "часть-целое" между агрегатом (целое) и его составной частью. Идя от целого (агрегата), можно прийти к его частям (атрибутам), но не наоборот (нельзя найти агрегирующий объект (контейнер), если только сведения о нем не являются случайно частью состояния агрегируемого объекта.).
В отличие от отношения обобщения, в агрегации части системы никак не обязаны наследовать ее свойства и поведение, поскольку являются самостоятельными сущностями. Более того, части целого обладают собственными атрибутами и операциями, которые существенно отличаются от атрибутов и операций целого.
Объект, являющийся атрибутом другого объекта (агрегата), имеет связь со своим агрегатом. Через эту связь агрегат может посылать ему сообщения.
Агрегация может означать физическое вхождение одного объекта в другой, но не обязательно.
9. Отношение зависимости между классами, отношение реализации.
Зависимость (dependency) – отношение между классами, при котором изменения в одном классе приводят к изменениям в другом классе (наследование, ассоциация и реализация – частные случаи отношения зависимости, имеющие особое назначение и специальную нотацию).
Зависимости между классами являются двусторонними: все классы в зависимости равноправны. Это так даже в тех случаях, когда имя зависимости как бы вносит направление в эту зависимость.
В языках программирования зависимости между классами (объектами) обычно реализуются с помощью ссылок (указателей) из одного класса (объекта) на другой. Представление зависимостей с помощью ссылок обнаруживает тот факт, что зависимость является свойством пары классов, а не какого-либо одного из них, т.е. зависимость - это отношение. Хотя зависимости между объектами двунаправлены, их не обязательно реализовать в программах как двунаправленные, оставляя ссылки лишь в тех классах, где это необходимо для программы.
Стереотипы отношения зависимости:
<<bind>> – назначение параметров шаблонному классу для получения нового конкретного класса
<<call>> – метод одного класса вызывает операцию другого класса
<<create>> – один класс создает экземпляр другого класса
<<permit>> или <<friend>> – разрешение одному классу использовать реализацию другого класса
<<use>> - общее обозначение
Понятие зависимости перенесено в объектно-ориентированную технологию проектирования программных систем из технологии проектирования (и моделирования) баз данных, где зависимости используются с давних пор. Языки программирования, как правило, не поддерживают явного описания зависимостей. Тем не менее описание зависимостей очень полезно при разработке программных систем.
Реализация (implementation) – отношение между интерфейсом и классом, его реализующим. Изображается реализация в виде пунктирной линии с большой незакрашенной стрелкой, указывающей на интерфейс, который определяет класс (каноническая форма) или в виде кружочка-интерфейса, соединенного с классом (свернутая форма).
Реализации настолько отличаются от зависимостей, обобщений и ассоциаций, что выделяются в отдельный тип отношений. Семантически реализация - это нечто среднее между обобщением и зависимостью, и нотация для нее несет в себе черты того и другого.
Чаще всего реализации используют для определения отношений между интерфейсом и классом или компонентом, который предоставляет объявленные в интерфейсе операции или услуга.
Пример: реализация интерфейса Список (имеющего абстрактные методы вставки, удаления) классами Связный и Двусвязный список (различные поля и реализация методов)
Отношение использования между классами.
Отношение использования между классами - отношение между классами, при котором один класс использует описание другого класса. Фактически при этом отношении один класс «знает» о существовании второго и «знает», по крайней мере, его интерфейс.
Возникает в случае: 1) методу данного класса передается объект используемого класса в качестве параметра; 2) если поле данного класса является объектом используемого класса (или указателем); 3) в методе данного класса создаются локальные объекты используемого класса; 4) метод данного класса выполняет действия над глобальным объектом используемого класса. Изменения в классах связанных между собой ведут к изменениям в других классах.
Пример.
class TemperatureController {
public:
TemperatureController(Location);
~TemperatureController();
void process(const TemperatureRamp&);
Minute schedule(const TemperatureRamp&) const;
private:
Heater h;
};
Класс TemperatureRamp упомянут как часть сигнатуры функции-члена process; это дает нам основания сказать, что класс TemperatureController пользуется услугами класса TemperatureRamp.
Отношение использования между классами соответствует равноправной связи между их экземплярами. Это то, во что превращается ассоциация, если оказывается, что одна из ее сторон (клиент) пользуется услугами другой (сервера). Пример клиент-серверных отношений показан на рис.
Рис. Отношение использования.
Дополнительно: Формы наследования
Порождение подклассов для специализации – полностью выполняется принцип подстановки. Существует различие между понятиями «тип» и «класс»: 2 класса принадлежат одному типу, если они реализуют один и тот же интерфейс.
Порождение класса для спецификации. Родительский класс – абстрактный, подклассы должны обеспечить реализацию поведения, заложенную в суперклассе.
Порождение с целью конструирования. Подкласс наследует структуру и поведение родительского класса, но не является его подтипом, при этом не поддерживается принцип подстановки.
Порождение классов для обобщения. Подкласс является более общим, чем суперкласс.
Порождение классов для расширения. Добавление структуры и поведения класса.
Порождение классов для ограничения. Возможности подкласса ограничены, по сравнению с родительским классом.
Порождение классов для варьирования. Дочерний и родительский класс можно поменять местами в иерархии наследования.
Порождение классов для комбинирования. Множественное наследование.