9. Проектирование классов

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

9.1. Проектирование классов, скрывающих информацию

Скрывающие информацию классы, проектируемые на этом эта- пе, подразделяются на категории в соответствии со стереотипом. Они документируются с помощью спецификаций интерфейсов.

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

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

www.pdffactory.com

можно привести файловую систему или систему управления базами данных. Класс-обертка базы данных скрывает информацию о том, как данные хранятся в базе, обычно реляционной. Класс-обертка мо-

жет также скрывать информацию об интерфейсе с унаследованной системой;

–интерфейсные классы, реализующие интерфейс с внешней средой, можно разделить на следующие группы:

классы интерфейса устройства, взаимодействующие с устрой-

ствами ввода/вывода;

классы интерфейса пользователя, осуществляющие человеко-

машинный интерфейс; классы интерфейса системы, общающиеся с внешней системой

или подсистемой;

–управляющие классы, координирующие совместную работу нескольких объектов, которые участвуют в прецеденте. Среди них можно выделить классы координации, классы, зависящие от состоя-

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

–классы прикладной логики, инкапсулирующие особенности ло- гики и алгоритмов приложения, подразделяются на классы бизнес-

логики и классы алгоритмов;

–внутренние программные классы, скрывающие те решения проектировщиков, которые могут впоследствии измениться. Их нель- зя определить на основе аналитической модели, они появляются в процессе проектирования.

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

Опишем, как выявляются операции, предоставляемые классами.

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

Представим несколько примеров проектирования классов. На диаграммах кооперации показано, как пассивный объект, операции

www.pdffactory.com

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

9.2.1. Проектирование операций классов на основе модели взаи-

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

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

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

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

www.pdffactory.com

Если же имя сообщения было глаголом, оно и становится именем операции. Имя, данное операции в проектной модели, должно отра- жать ее назначение в классе.

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

Рассмотрим, к примеру, класс Карточка Банкомата, который инкапсулирует информацию, прочитанную с карточки. Из диаграммы кооперации в составе аналитической модели (рис.9.la) видно, что объект Интерфейс Устройства Считывания Карточек посылает со-

общение Данные от Устройства Считывания сущностному объекту Карточка Банкомата. Позже объект Интерфейс Клиента отправляет сообщение Запрос Карточки объекту Карточка Банкомата, который возвращает Данные Карточки. На этапе проектирования определяет- ся точный интерфейс класса. Простое сообщение Данные от Устрой- ства Считывания из проектной модели (рис.9.1б) отображается на вызов операции писать(данныеКарточки, предоставляемой объектом

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

www.pdffactory.com

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

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

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

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

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

www.pdffactory.com