2. Атрибуты

Атрибут - это элемент информации, связанный с классом. Например, у класса Company (компания) могут быть атрибуты Name (Название), Address (Адрес) и NumberOfEmployees (Число служащих).

Существует множество источников выявления атрибутов. Для начала, взгляните на описание варианта использования. Ищите имена существительные в потоке событий. Некоторые из них будут классами или объектами, другие - действующими лицами, и, наконец, последняя группа - атрибутами. Например, в потоке событий может быть написано: «Пользователь вводит имя сотрудника, его адрес, номер социальной страховки и номер телефона». Это означает, что у класса Сотрудник имеются атрибуты Имя, Адрес, Номер страховки и Номер телефона.

Атрибуты можно также искать в документации, описывающей требования к системе. Ищите такие требования, которые описывают собираемые системой данные. Любой элемент собираемой информации может быть атрибутом класса.

Наконец, взгляните на структуру базы данных. Если она уже определена, поля в ее таблицах дадут вам хорошее представление об атрибутах. Часто имеется однозначное соответствие между таблицами базы данных и классами-сущностями. Если вернуться к предыдущему примеру, то в таблице Сотрудник должны быть поля Имя, Адрес, Номер телефона и Номер страховки. Соответствующий класс Сотрудник также имеет атрибуты Имя, Адрес, Номер телефона и Номер страховки. Следует отметить, однако, что такое однозначное соответствие имеется не всегда. Подходы к проектированию баз данных и классов могут различаться. В частности, реляционные базы данных не поддерживают наследование непосредственно.

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

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

Определив атрибуты, внимательно соотнесите их с соответствующими классами. Атрибут должен соответствовать классу. Например, класс «Сотрудник» может содержать «Имя» и «Адрес», но не должен включать сведения о выпускаемой компанией продукции.

Относитесь осторожно к классам, у которых атрибутов слишком много, возможно, это является указанием на то, что его надо разделить на два меньших. Если в классе 10 или 15 атрибутов, внимательно изучите его. Он может быть вполне приемлемым, только убедитесь, что все его атрибуты нужны и, действительно, должны принадлежать этому классу.

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

Иногда могут возникнуть сомнения, соответствует ли обнаруженная вами информация атрибуту или классу. Рассмотрим, например, такой атрибут, как имя компании. Вы можете задать вопрос, является ли он атрибутом класса «Person» (человек) или компания является свои собственным классом. Ответ зависит от того, какое приложение вы разрабатываете. Если вы собираете сведения о компании, и имеется связанное с ней поведение, она может быть классом. Допустим, например, что вы проектируете систему работы с заказчиками. В таком случае вам может потребоваться информация о компаниях, которым вы поставляете товары или услуги. Вы захотите узнать, сколько сотрудников работает в той компании, ее имя и адрес, контактный телефон и т.д.

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

Кроме этого надо рассмотреть, имеется ли поведение у подозрительной информации. Если в вашем приложении у компании имеется некоторое выраженное поведение, лучше всего моделировать ее как класс. Если поведения нет, то это, скорее всего, атрибут.

Атрибуты содержатся внутри класса, они скрыты от других классов. Поэтому может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility).

У атрибута можно определить четыре возможных значения этого параметра. Рассмотрим каждый из них в контексте примера (Рис. 12). Пусть у нас имеется класс Employee с атрибутом Address и класс Company:

• Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В таком случае класс Company может изменить значение атрибута Address класса Employee. В соответствии с нотацией UML общему атрибуту предшествует знак +.

• Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Класс Employee будет знать значение атрибута Address и сможет изменять его, но класс Company не сможет его ни увидеть, ни редактировать. Если это понадобится, он должен попросить класс Employee просмотреть или изменить значение этого атрибута, что обычно делается с помощью общих операций. Закрытый атрибут обозначается знаком "-" в соответствии с нотацией UML.

• Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам. Допустим, что у нас имеется два различных типа сотрудников - с почасовой оплатой и на окладе. Таким образом, мы получаем два других класса HourlyEmp и SalariedEmp, являющихся потомками класса Employee. Защищенный атрибут Address можно просмотреть или изменить из классов Employee, HourlyEmp и SalariedEmp, но не из класса Company. Нотация UML для защищенного атрибута - это знак "#".

• Package or Implementation (пакетный). Предполагает, что данный атрибут является общим, но только в пределах его пакета. Допустим, что атрибут Address имеет пакетную видимость. В таком случае он может быть изменен из класса Company, только если этот класс находится в том же пакете. Этот тип видимости не обозначается никаким специальным значком.

Employee
#Employee ID : Integer = О #SSN : String #Salary: float +Address : String +City: String +State : String +Zip Code : long +Departament: : String	Защищенный Защищенный Защищенный Открытый Открытый Открытый Открытый Открытый
+Hire() +Fire() +Promote() +Demote() +Transfer()	Открытый Открытый Открытый Открытый Открытый

Рис. 12. Видимость атрибутов

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

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