Обычно в программах на C++ использование силовых классов реализуется с помощью указателей. Так, в нашем примере класс Car (соответствующий классу проекта Автомобиль) будет содержать указатель на объект класса PerformanceCharacteristics (рис. 18.20). Если хотите потренироваться, создайте самостоятельно силовые классы для дискриминаторов Кузов (body) и Двигатель (engine).
Class Car:public Vehicle
{
public:
Car();
~Car();
//другие открытые методы опущены
private:
PerformanceCharacteristics*pPerformance;
};
И наконец, силовые классы дают возможность создавать новые типы данных во время выполнения программы.
Поскольку каждый логический тип различается только атрибутами ассоциированных с ним силовых классов, то эти атрибуты могут быть параметрами конструкторов данных силовых классов. Это означает, что можно во время выполнения программы создавать новые типы автомобилей, изменяя установки атрибутов силовых классов. Число новых типов, которые можно создать во время выполнения программы, ограничивается только числом логических комбинаций атрибутов разных силовых классов.
В модели проекта важно указать не только отношения между классами, но и принципы их взаимодействия. Например, классы Расчетный счет, ATM и Квитанция взаимодействуют с классом Клиент в ситуации Снятие со счета. Возвращаясь к виду последовательных диаграмм, которые использовались в начале анализа (см. рис. 18.11), рассмотрим теперь взаимодействие классов на основе определенных для них методов, как показано на рис. 18.21.
Рис. 18.19. Дискриминатор как силовой класс
Рис. 18.20. Отношение между объектом класса Автомобиль и связанным с ним силовым классом
Рис. 18.21. Диаграмма взаимодействия классов
Эта простая диаграмма показывает взаимодействие между несколькими классами проекта при определенной ситуации использования программы. Предполагается, что класс ATM делегирует классу Расчетный счет ответственность за учет остатка денег на счете, в то время как Расчетный счет делегирует классу ATM ответственность за доведение этой информации пользователю.
Существует два вида диаграмм взаимодействий классов. На рис. 18.21 показана диаграмма последовательности действий. Та же ситуация, но в другом виде, изображена на рис. 18.22 и называется диаграммой сотрудничества. Диаграмма первого типа определяет последовательность событий за некоторое время, а диаграмма второго типа — принципы взаимодействия классов. Диаграмму сотрудничества можно создать прямо из диаграммы последовательности. Такие средства, как Rational Rose, автоматически выполнят это задание после щелчка на кнопке.
Рис. 18.22. Диаграмма сотрудничества
Диаграммы переходов состояний
После того как стали понятными взаимодействия между объектами, надо определить различные возможные состояния каждого из них. Моделировать переходы между различными состояниями можно в диаграмме состояний (или диаграмме переходов состояний). На рис. 18.23 показаны различные состояния класса Расчетный счет при регистрации клиента в системе.
Каждая диаграмма состояний начинается с состояния Начало и заканчивается нулем или некоторым другим концевым состоянием. Каждое состояние имеет свое имя, и в переходах между состояниями могут быть установлены Сторожа, представляющие собой условия, при выполнении которых возможен переход от состояния к состоянию.
Клиент может в любое время передумать и не регистрироваться. Он может это сделать после того, как вставил карточку или после ввода пароля. В любом случае система должна принять его запрос на аннулирование и вернуться в состояние Не зарегистрирован (рис. 18.24).
Как видите, в более сложной диаграмме, содержащей много состояний, указание на каждом шаге возможности перехода к состоянию Отмена внесет сумятицу. Особенно раздражает тот факт, что отмена является исключительным состоянием, отвлекающим от анализа нормальных переходов между состояниями. Эту диаграмму можно упростить, используя сверхсостояние (рис. 18.25).
Читать дальше