
- •1. Жизненный цикл программной системы.
- •2. Классический подход к созданию программных систем.
- •3. Понятия связности модулей и сцепления модулей.
- •4. Структурное программирование.
- •Структурное тестирование программного обеспечения
- •1. Связь процессов тестирования и процессов проектирования.
- •2. Уровни тестирования и виды тестирования.
- •3. Стратегия тестирования.
- •4. Тестирование программного модуля.
- •5. Восходящее и нисходящее тестирование.
- •6. Методы тестирования: модифицированный нисходящий, монолитный, сандвич, модифицированный сандвич.
- •7. Системное тестирование: метод функциональных диаграмм.
- •Объектно-ориентированный подход к разработке по
- •1. Абстрагирование и инкапсуляция
- •2. Модульность программных систем
- •3. Виды иерархий в программных системах.
- •4. Понятие объекта. Состояние, поведение и индивидуальность объекта.
- •5. Отношение между объектами: использование, включение.
- •6. Отношение простого наследования классов.
- •7. Добавление, замещение и уточнение методов класса при наследовании.
- •8. Отношение ассоциации между классами, включая агрегацию.
- •9. Отношение зависимости между классами, отношение реализации.
- •Шаблоны проектирования
- •1. Шаблон «Одиночка» Singleton
- •2. Шаблон «Абстрактная фабрика» Abstract Factory
- •3. Шаблон «Декоратор» Decorator
- •4. Шаблон «Стратегии» Strategy
- •5. Компоновщик.
- •6. Шаблон «Наблюдатель» Observer
- •7. Архитектурные шаблоны. Унифицированный процесс разработки по (rup)
- •1. Основные черты. Фазы и основные потоки работ.
- •2. Документ «Видения». Модель и словарь предметной области.
- •3. Функциональные и нефункциональные требования к системе. Варианты использования системы.
- •4. Прецеденты и отношения между прецедентами.
- •5. Модель анализа и классы анализа.
- •6. Архитектурное представление.
5. Отношение между объектами: использование, включение.
Типы отношений
Отношения двух любых объектов основываются на предположениях, которыми один обладает относительно другого: об операциях, которые можно выполнять, и об ожидаемом поведении. Особый интерес для объектно-ориентированного анализа и проектирования представляют два типа иерархических соотношений объектов:
связи (отношение использования);
агрегация (отношение включения);
Связи
Связь – физическое или концептуальное соединение между объектами.
Связь - это специфическое сопоставление, через которое клиент запрашивает услугу у объекта-сервера или через которое один объект находит путь к другому.
На рис. показано несколько разных связей. Они отмечены линиями и означают пути прохождения сообщений. Сами сообщения показаны стрелками и помечены именем операции. На рисунке объект aController связан с двумя объектами класса DisplayItem. В свою очередь, оба, вероятно, связаны с aView, но нам была интересна только одна из этих связей. Только вдоль связи один объект может послать сообщение другому.
Связь между объектами и передача сообщений обычно односторонняя (как на рисунке; хотя технически она может быть и взаимной). Подобное разделение прав и обязанностей типично для хорошо структурированных объектных систем. Заметьте также, что хотя передаваемое сообщение инициализировано клиентом (в данном случае aController), данные передаются в обоих направлениях. Например, когда aController вызывает операцию move для пересылки данных объекту а, данные передаются от клиента серверу, но при выполнении операции isUnder над объектом b, результат передается от сервера клиенту.
Участвуя в связи, объект может выполнять одну из следующих трех ролей:
∙ Актер. Объект может воздействовать на другие объекты, но сам никогда не подвергается воздействию других объектов; в определенном смысле это соответствует понятию активный объект.
∙ Сервер. Объект может только подвергаться воздействию со стороны других объектов, но он никогда не выступает в роли воздействующего объекта.
∙ Агент. Такой объект может выступать как в активной, так и в пассивной роли; как правило, объект-агент создается для выполнения операций в интересах какого-либо объекта-актера или агента.
Рис. Связи.
Агрегация
Агрегация описывает отношения целого и части, приводящие к соответствующей иерархии объектов, причем, идя от целого (агрегата), мы можем придти к его частям (атрибутам). На рис. объект rampController имеет связь с объектом growingRamp и атрибут h класса Heater (нагреватель). В данном случае rampController - целое, a h - его часть. Другими словами, h - часть состояния rampController. Исходя из rampController, можно найти соответствующий нагреватель. Однако по h нельзя найти содержащий его объект (называемый также его контейнером), если только сведения о нем не являются случайно частью состояния h.
Рис. Агрегация.
Агрегация может означать физическое вхождение одного объекта в другой, но не обязательно.
Выбирая одно из двух - связь или агрегацию - надо иметь в виду следующее. Агрегация иногда предпочтительнее, поскольку позволяет скрыть части в целом. Иногда наоборот предпочтительнее связи, поскольку они слабее и менее ограничительны. Принимая решение, надо взвесить все.
Объект, являющийся атрибутом другого объекта (агрегата), имеет связь со своим агрегатом. Через эту связь агрегат может посылать ему сообщения.