9.2. Проектирование операций классов

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

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

9.2.7. Проектирование операций классов на основе модели взаимодействия. Воспользуемся моделью взаимодействия объектов для выявления операций классов. Для этой цели годится как диаграмма коопера­ции, так и диаграмма последовательности. Операции классов определяются пу­тем рассмотрения того, как объект данного класса взаимодействует с другими объектами, поскольку взаимодействие двух объектов состоит в том, что один из них вызывает операцию другого. При проектировании операций классов мы бу­дем применять в основном диаграммы кооперации.

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

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

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

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

Рассмотрим, к примеру, класс Карточка Банкомата, который инкапсулирует информацию, прочи­танную с карточки. Из диаграммы кооперации в составе аналитической модели (рис.9.la) видно, что объект Интерфейс Устройства Считывания Карточек посылает сообщение Данные от Устройства Считывания сущностному объек­ту Карточка Банкомата. Позже объект Интерфейс Клиента отправляет сооб­щение Запрос Карточки объекту Карточка Банкомата, который возвращает Данные Карточки. На этапе проектирования определяется точный интерфейс класса. Простое сообщение Данные от Устройства Считывания из проектной модели (рис.9.1б) отображается на вызов операции писать(данныеКарточки, предоставляемой объектом Карточка Банкомата. Сообщение Запрос Кар­точки отображается на вызов операции читать объекта Карточка. Простому сообщению Данные Карточки соответствует выходной параметр операции чи­тать. Вызовы операций изображаются с помощью нотации UML для синхрон­ных сообщений. На рис.9.1в показан класс абстрагирования данных Карточка Банкомата. Представлены как атрибуты, так и операции. У операции писать имеется один входной параметр – данные Карточки. У операции читать есть один выходной параметр – прочитанные данныеКарточки.

Рис.9.1. Пример класса абстрагирования данных:

а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма кооперации); в – проектная модель (диаграмма классов)

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

9.2.2. Проектирование операций классов на основе конечного автомата. Операции классов можно также вывести из диаграммы состояний. На ней пред­ставлены действия и деятельности, инициируемые в результате перехода состоя­ний. Действия, как правило, отображаются на операции класса. На диаграммах состояний показаны все зависящие от состояния действия и деятельности. Если действия выполняются пассивными классами, то они выводятся из диаграммы состояний.

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

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