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

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

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

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

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

Вершина в диаграмме классов — класс (рис.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. Диалоговое окно для задания свойств операций класса