Организация атрибутов и операций

П ри изображении класса необязательно сразу показывать все его атрибуты и операции. Как правило, это попросту невозможно - их чересчур много для од­ного рисунка, - да и не требуется (поскольку для данного представления системы лишь небольшое подмножество атрибутов и операций имеет значение). По этим причинам класс обычно сворачивают, то есть изображают лишь некоторые из имею­щихся атрибутов и операций, а то и вовсе опускают их. Таким образом, пустой раз­дел в соответствующем месте прямоуголь­ника может означать не отсутствие атри­бутов или операций, а только то, что их не сочли нужным изобразить. Явным обра­зом наличие дополнительных атрибутов или операций можно обозначить, поста­вив в конце списка многоточие.

Для лучшей организации списков атри­бутов и операций можно снабдить каждую группу дополнительным описанием, вос­пользовавшись стереотипами (см. главу 6), как показано на рис. 4.7.

Обязанности

О бязанности (Responsibilities) класса - это своего рода контракт, которому он должен подчиняться. Определяя класс, вы постулируете, что все его объекты име­ют однотипное состояние и ведут себя одинаково. Выражаясь абстрактно, соот­ветствующие атрибуты и операции как раз и являются теми свойствами, посредст­вом которых выполняются обязанности класса. Например, класс Wall (Стена) отвечает за информацию о высоте, ширине и толщине. Класс FraudAgent (Агент ПоПредотвращениюМошенничества), который встречается в приложениях по обработке кредитных карточек, отвечает за оценку платежных требований - за­конные ли они, подозрительные или подложные. Класс TemperafcureSensor (ДатчикТемпературы) отвечает за измерение температуры и подачу сигнала тре­воги в случае превышения заданного уровня. (Обязанности класса - это пример определенного стереотипа, см. главу 6.)

Моделирование классов лучше всего начинать с определения обязанностей сущностей, которые входят в словарь системы (см. главу 9). На этом этапе особенно полезны будут такие методики, как применение CRC-карточек и анализ прецедентов. В принципе число обязанностей класса может быть произвольным. но на практике хорошо структурированный класс имеет по меньшей мере одну обя­занность; с другой стороны, их не должно быть и слишком много. При уточнении модели обязанности класса преобразуются в совокупность атрибутов и операций, которые должны наилучшим образом обеспечить их выполнение.

Графически обязанности изображают в особом разделе в нижней части никто граммы класса (см. рис. 4.8). Их можно указать также в примечании; подроби» о примечаниях рассказывается в главе 6.

Примечание Обязанности оформляются в виде произвольно составленного тек­ста. Как правило, каждая обязанность излагается в одном пред­ложении или, на крайний случай, в коротком абзаце.

Другие свойства

При создании абстракций вам чаще все­го придется иметь дело с атрибутами, опе­рациями и обязанностями. Для большин­ства моделей этого вполне достаточно, чтобы описать важнейшие черты семантики классов. Но иногда приходится визуализировать или специфицировать и другие особенности, как то: видимость отдельных атрибутов и операций, специфические для конкретного языка программирования свой­ства операции (например, является ли она полиморфной или константной) или даже исключения, которые объекты класса могут возбуждать или обрабатывать. Эти и многие другие особенности тоже можно выразить в UML, но в таком случае требу­ется обращение к более развитым возможностям языка (см. главу 9).

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

Переходя к разработке более сложных моделей, вы всякий раз будете сталки­ваться с теми же классами (которые представляют, например, параллельные про­цессы и потоки или физические сущности, в частности апплеты, компоненты JavaBeans и СОМ+, файлы, Web-страницы, аппаратные средства). Поскольку по­добные классы очень распространены и представляют важные архитектурные аб­стракции, в UML имеются такие элементы, как активные классы (описывающие процессы и нити, см. главу 22), компоненты (соответствующие физическим про­граммным компонентам, см. главу 24) и узлы (представляющие аппаратные средст­ва, см. главу 26).

Наконец, классы редко существуют сами по себе. При построении моделей следует обращать внимание на группы взаимодействующих между собой классов. В языке UML такие сообщества принято называть кооперациями и изображать на диаграммах классов (см. главу 8).