Динамические модели объектно-ориентированных программных систем

Отношения в диаграммах классов

Вершины в диаграммах классов

Статические модели объектно-ориентированных программных систем

Основным средством для представления статических моделей являются диаграммы классов. «Статичность» этих моделей состоит в том, что здесь не показывается динамика изменений системы во времени. Диаграммы используются:

● в ходе анализа — для указания ролей и обязанностей сущностей, которые обеспечивают поведение системы;

● в ходе проектирования — для фиксации структуры классов, которые формируют системную архитектуру.

Вершина в диаграмме классов — класс (рис.3.8). Имя класса указывается всегда, свойства и операции — выборочно. Предусмотрено задание области видимости свойства или операции (public, private, protected, package).

Рисунок 3.8. Обозначение класса

В языке UML определены три уровня видимости:

● public - любой клиент класса может использовать свойство (операцию), protected - любой наследник класса может использовать свойство (операцию),

● private - свойство (операция) может использоваться только самим классом,

● package – свойство (операция) может использоваться в пределах пакета.

Если видимость не указана, считают, что свойство объявлено с публичной видимостью.

На рис 3.9. показано диалоговое окно CASE средства Rational Software Architect для задания свойств атрибутов класса.

Рисунок 3.9.Диалоговое окно для задания свойств атрибутов класса

В общем случае, атрибуты рекомендуется делать закрытыми или защищенными.

Если свойство (операция) подчеркивается, его областью действия является класс. В этом случае все его экземпляры (объекты) используют общее значение этого свойства (static), в противном случае у каждого экземпляра свое значение свойства. Для задания статических атрибутов (операций) используется флаг static.

Операции реализуют связанное с классом поведение. Операция включает три части – имя, параметры и тип возвращаемого значения. Параметры – это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату действия операции.

В классе может существовать четыре различных типа операций.

● Операции реализации (implementor operations) реализуют некоторые бизнес-функции. Такие операции можно найти, исследуя диаграммы взаимодействия. Диаграммы этого типа фокусируются на бизнес-функциях, и каждое сообщение диаграммы, скорее всего, можно соотнести с операцией реализации. Каждая операция реализации должна быть легко прослеживаема до соответствующего требования. Это достигается на различных этапах моделирования. Операция выводится из сообщения на диаграмме взаимодействия, сообщения исходят из подробного описания потока событий, который создается на основе варианта использования, а последний – на основе требований. Возможность проследить всю эту цепочку позволяет гарантировать, что каждое требование будет реализовано в коде, а каждый фрагмент кода реализует какое-то требование.

● Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов.

● Операции доступа(селекторы и модификаторы).Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа (access operations). Такой подход дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позволяет осуществить к ним контролируемый доступ. Создание операций Get и Set (получения и изменения значения) для каждого атрибута класса является стандартом.

● Вспомогательными (helper operations) называются такие операции класса, которые необходимы ему для выполнения его функций, но о которых другие классы не должны ничего знать. Это закрытые и защищенные операции класса.

На рис 3.10. показано диалоговое окно CASE средства Rational Software Architect для задания свойств атрибутов класса.

Рисунок 3.10. Диалоговое окно для задания свойств операций класса

В диаграммах классов можно использовать следующие отношения:

Ассоциации отображают структурные отношения между экземплярами классов, то есть соединения между объектами. Каждая ассоциация может иметь метку — имя, которое описывает природу отношения (рис. 3.10).

Рисунок 3.11 Отношение ассоциации

Когда класс участвует в ассоциации, он играет в этом отношении определенную роль. Роль определяет, каким представляется класс на одном конце ассоциации для класса на противоположном конце ассоциации. Один и тот же класс в разных ассоциациях может играть разные роли. Часто важно знать, как много объектов может соединяться через экземпляр ассоциации. Это количество называется мощностью роли в ассоциации.

В языке UML ассоциации могут иметь свойства. Свойства класса-ассоциации характеризуют не один, а пару объектов, в данном случае — Профессор и Университет (рис. 3.12).

Рисунок 3.12. Класс-ассоциация

Отношения агрегации и композиции в языке UML считаются разновидностями ассоциации, применяемыми для отображения структурных отношений между «целым» (агрегатом) и его «частями». Агрегация показывает отношение по ссылке (в агрегат включены только указатели на части), композиция — отношение физического включения (в агрегат включены сами части).

Агрегация – это связь между целым и его частью. Например, у вас может быть класс Автомобиль, а также классы Двигатель, Покрышки и классы для других частей автомобиля. В результате объект класса Автомобиль будет состоять из объекта класса Двигатель, четырех объектов Покрышек и т. д. (рис. 3.13).

Рисунок 3.13 Отношение агрегации

Согласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого (агрегата): не могут существовать без целого, удаление целого распространяется на его части. Например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (рис.3.14).

Рисунок 3.14 Отношение агрегации

С помощью обобщений показывают связи наследования между двумя классами. Большинство объектно-ориентированных языков непосредственно поддерживают концепцию наследования. Она позволяет одному классу наследовать все атрибуты, операции и связи другого. На языке UML связи наследования называют обобщениями и изображают в виде стрелок от класса-потомка к классу-предку (рис. 3.15).

Рисунок 3.15. Отношение обобщения

Связи зависимоститакже отражают связь между классами, но они всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Зависимости изображают в виде стрелки, проведенной пунктирной линией.

Т. е. это отношение является отношением использования между клиентом (зависимым элементом) и поставщиком (независимым элементом). Обычно операции клиента:

● вызывают операции поставщика;

● имеют описания, в которых возвращаемое значение или аргументы принадлежат классу поставщика.

Рисунок 3.16. Отношение зависимости

На рис. 3.16. показано отношение зависимости между клиентом (Группой) и поставщиком (Шаблоном для поиска). В классе Группа есть метод Поиск, параметром которого является объект класса Шаблон.

Реализация – отношение между классами, при котором класс-приемник реализует операции, заявленные в классе-источнике (интерфейсе). Интерфейс – это абстрактный класс, в котором все составляющие — атрибуты и операции — абстрактны, он не может иметь экземпляров. Интерфейс нужен для того, чтобы определить логику работы с данной иерархией классов. На рис. 3.17. показано, что класс Студент реализует интерфейс IStudy, но способы реализации операций интерфейса у классов могут быть разные.

Рисунок 3.17. Отношение реализации

Динамические модели обеспечивают представление поведения систем, в них отражается изменение состояний в процессе работы системы (в зависимости от времени).

Для моделирования поведения системы используют:

● автоматы;

● взаимодействия.

Автомат (State machine) описывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни. Взаимодействие описывает поведение в терминах обмена сообщениями между объектами.

Таким образом, автомат задает поведение системы как цельной, единой сущности; моделирует жизненный цикл единого объекта. Поэтому автоматный подход удобно применять для формализации динамики отдельного трудного для понимания блока системы. Автоматы отображают с помощью:

● диаграмм схем состояний;

● диаграмм деятельности.

Взаимодействия определяют поведение системы в виде коммуникаций между его частями (объектами), представляя систему как набор совместно работающих объектов. Именно поэтому взаимодействия считают основным аппаратом для фиксации полной динамики системы. Взаимодействия отображают с помощью:

● диаграмм сотрудничества (кооперации);

● диаграмм последовательности.