Как класс изображается на диаграмме UML?
Архитектор программного обеспечения в первую очередь обращает внимание на объекты предметной области. Программист же концентрируется на поведении этих объектов, пользуясь классами, к которым они принадлежат.
Вот поэтому-то диаграмма классов и является одной из важнейших диаграмм UML. Она используется для документирования программных систем.
Основным компонентом диаграммы классов является класс. Что такое класс, мы уже говорили ранее, когда знакомились с видами диаграмм UML. Рассмотрим тонкости обозначений, используемых на этих диаграммах. Существует значительное число нюансов, которые делают использование диаграмм классов достаточно непростым делом.
Класс на диаграмме изображается в виде прямоугольника, разделенного горизонтальными линиями на три части. В первой части указывается название класса. Как правило, имя класса состоит из одного, максимум двух слов. Вторая часть содержит перечень атрибутов класса, которые характеризуют тот или иной объект этого класса в модели предметной области. Третья часть содержит перечень операций, отражающих его поведение в модели предметной области (рис. 4.1). Все очень просто, не так ли?
Рис. 4.1.
Как на диаграмме отображаются «внутренности» класса?
Пользователю об этом знать необязательно, более того, абсолютно не нужно. Для человека, использующего его, объект выступает в роли черного ящика. Скрывая от пользователя внутренне устройство объекта, мы обеспечиваем его надежную работу. Сейчас мы рассмотрим, как убрать из поля зрения пользователя то, что ему знать не нужно.
Определим понятие пользователя класса в контексте задачи программирования. В данном случае в таком качестве выступает программист, использующий в своей программе, созданные кем-то.
Главное, что ему надо - какие атрибуты надо модифицировать и какие операции использовать, чтобы заставить объект работать именно так, как ему нужно, а не то, какой код внутри класса. Действительно, многие ли знают, как именно устроен и по каким принципам работает, например, телевизор - объект класса "Бытовой прибор"?
Сокрытие от пользователя внутреннего устройства объектов называется инкапсуляцией. Если говорить более "научным" языком, то инкапсуляция - это защита отдельных элементов объекта, не затрагивающих существенных характеристик его как целого. Инкапсуляция нужна не только для того, чтобы создать иллюзию простоты объекта для пользователя (по словам Г. Буча). Но вернемся к примеру с телевизором. Нам этот прибор кажется очень простым только потому, что при работе с ним мы используем простой и понятный интерфейс - пульт дистанционного управления. Мы знаем: для того чтобы увеличить громкость звука, надо нажать вот эту кнопку, а чтобы переключить канал - вот эту. Как телевизор устроен внутри, мы не знаем. Более того - в отсутствие пульта ДУ такое знание было бы неудобным для нас и весьма опасным для самого телевизора, вздумай мы увеличить громкость с помощью паяльника. Поэтому-то пульт ДУ и защищает от нас "внутренности" телевизора! Вот так инкапсуляция реализуется в реальном мире.
В программировании инкапсуляция обеспечивается немного по-другому - с помощью так называемых модификаторов видимости. С их помощью можно ограничить доступ к атрибутам и операциям объекта со стороны других объектов.
Если атрибут или операция описаны с модификатором private, то доступ к ним можно получить только из операции, определенной в том же классе.
Если же атрибут или операция описаны с модификатором видимости public, то к ним можно получить доступ из любой части программы.
Модификатор protected разрешает доступ только из операций этого же класса и классов, создаваемых на его основе. В языках программирования могут встречаться модификаторы видимости, ограничивающие доступ на более высоком уровне, например, к классам или их группам, однако смысл инкапсуляции от этого не изменяется. В UML атрибуты и операции с модификаторами доступа обозначаются специальными символами слева от их имен:
| Символ | Значение |
| + | public - открытый доступ |
| - | private - только из операций того же класса |
| # | protected - только из операций этого же класса и классов, создаваемых на его основе |
Рассмотренный ранее пример с телевизором средствами UML (конечно же, это очень высокоуровневая абстракция) можно изобразить так (рис. 4.2):
Рис. 4.2. Обозначении доступа методов и свойств класса
Все понятно и предельно просто? Зачем, например, пользователю знать числовые значения частот каналов? Он знает, что достаточно запустить процедуру автоматического поиска каналов и телевизор все сделает за него. Вот вам и инкапсуляция - оказывается, она повсюду вокруг нас. Оглянитесь и подумайте, сколько вещей вокруг имеют скрытые свойства и выполняют скрытые операции.
