Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Поведение и структура класса





Класс воплощает в себе множество функциональных обязанностей, которые обусловливают поведение (behavior) объектов этого класса. Обязанности реализуются по­средством операций, определяемых в контексте класса. Операция должна осуществ­лять всего одну функцию, но успешно и во всей ее полноте. Например, класс "предложение курса" следует снабдить функциями регистрации студента и отмены та­ковой. Эти обязанности представляются двумя операциями: одна из них ответственна за регистрацию студента на курс, а другая — за отмену регистрации. Каждая операция класса поступает в распоряжение всех его объектов.

Структура (structure) объекта определяется множеством атрибутов класса. Атрибут представляет собой определение порции данных, доступной для объекта. Объекты класса обладают собственными значениями каждого из атрибутов. Например, в состав класса "курс" уместно включить атрибуты "наименование", "описание" и "количество учебных часов". В этом случае каждому объекту класса "курс" ставится в соответствие некоторая комбинация значений названных атрибутов. Значения одного и того же ат­рибута в нескольких объектах не обязаны быть уникальными — те или иные универси­тетские курсы могут обладать, скажем, равной временной "протяженностью".

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



Если объект не нуждается в атрибутах и/или операциях, стоит еще раз присмот­реться к определению соответствующего класса. Это может свидетельствовать о том, что класс не является самодостаточным и потому подлежит объединению с каким-либо иным классом. С другой стороны, избыток данных или их разноречивость также недопустимы. Предположим, что в определение класса "предложение курса" помимо атрибутов "наименование курса", "номер курса", "номер предложения", "место проведения занятий" и "время проведения занятий" включен атрибут "количество предложений курсов по факультету". В компетенцию объекта класса определенно входит сохра­нение первых пяти атрибутов, чего не скажешь о последнем. Было бы лучше связать класс "предложение курса" с отдельным классом "факультет": напомним общее правило, гласящее, что класс должен представлять какую-либо одну основную сущность.

Лекция №5

Создание операций

 

Сообщения в диаграммах взаимодействия, как правило, соотносятся с операциями (operations), определенными в составе класса-приемника. Однако встречаются ситуа­ции, когда сообщение не "превращается" в операцию. Если класс, которому адресова­но сообщение, является классом границ, представляющим тип некоторого элемента графического интерфейса пользователя, сообщение выражает одно из требований, предъявляемых к интерфейсу. Подобные типы сообщений обычно реализуются в ви­де тех или иных управляющих компонентов интерфейса (скажем, диалоговых окон или их отдельных частей) и не преобразуются в операции напрямую, поскольку соответствующих функции принимает на себя компонент управления как таковой. На­пример, активный субъект "профессор", намеревающийся инициировать сценарии внесение предложения курса", обязан ввести пароль, чтобы зарегистрировав в системе. Эта функция описывается сообщением, направляемым в адрес объекта класса границ "опции выбора курсов", и не реализуется в форме самостоятельной операции класса интерфейса пользователя — в данном случае речь идет всего лишь о поле ввода текста, размещенном в пределах некоторого диалогового окна. Вообще говоря, все сообщения, направляемые и получаемые активными субъектами, заслужи­вают отдельного изучения. Если в роли активного субъекта выступает человек, сооб­щение выражает выполняемое им действие и потому достойно упоминания в печат­ном руководстве пользователя, а не реализации в виде операции, осуществляемой системой. Вернемся к сценарию "внесение предложения курса": тот факт, что субъект-"профессор" должен предварительно ввести пароль, дабы получить доступ к системе, является важным требованием, которое заслуживает отражения в памятке пользова­теля. Если же активный субъект представляет внешнюю систему, создается некото­рый класс, обеспечивающий поддержку протокола взаимодействия систем, и в этом случае сообщение отображается в виде определенной операции такого класса.

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

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

Сигнатура операции способна свидетельствовать о наличии некоторой связи между классами. Если тип аргумента или возвращаемого значения операции относится к числу "стандартных" (таких, как, скажем, String), соответствующая связь на диа­грамме обычно не отображается. В противном случае (когда аргументы и/или воз­вращаемые значения принадлежат к пользовательским типам) предполагается суще­ствование набора связей между классами. Например, аргументами операции назначить профессора" класса "курс" служат объекты типов "профессор" и "пред­ложение курса", что обусловливает наличие связей между классами Связи, основанные на сигнатурах операций, изначально моделируются в виде ассоциаций, а позже, в ходе развития системы, могут трансформироваться в связи зависи­мости (за подробностями обращайтесь к главе 12). По мере пополнения модели связями, обусловленными сигнатурами операций, подлежат пересмотру и связи пакетов. Например, поскольку в модель добавлена связь между классами "курс" и "профессор", отсюда следует факт существования связи между пакетами "курсы" и "личные данные".

 

Создание атрибутов

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

 









Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2018 zdamsam.ru Размещенные материалы защищены законодательством РФ.