Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 49

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 49)

О них мырасскажем в следующем разделе.Вызов операции - наиболее общая форма сообщения. Она подчиняетсяранее описанному синтаксису операций, но, в отличие от него, здесь могутбыть приведены фактические параметры, подходящие к сигнатуре операции:•N()только имя операциивозвращаемое значение, имя и фактические•RN(arguments)параметры операции.Сопоставление фактических параметров с формальнымиосуществляется в порядке следования. Если возвращаемый операцией объектили фактические параметры используют неквалифицированные имена,совпадающие с другими неквалифицированными именами на диаграмме, топодразумевается, что они именуют одинаковые объекты, а следовательно, ихклассы должны подходить к сигнатуре операции. Таким образом, мы можемпредставлять взаимодействия, в ходе которых объекты передаются в качествепараметров или возвращаются, как результат операции.Сообщение может извещать о событии.

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

Повторение порядковых номеров или их отсутствиеговорит о частичной упорядоченности сообщений.Пример. На рис. 5-25 показана диаграмма объектов для нашеготепличного хозяйства в контексте категории классов Planning(планирование; описана на рис. 5-7). Цель этой диаграммы проиллюстрировать сценарий выполнения обычной функции системы, аименно, прогнозирование затрат на сбор урожая некоторого посева.Выполнение этой функции требует сотрудничества несколькихразличных объектов. Сценарий начинается с вызова объектом PlanAnalyst(анализатор планов) операции timeToHarvest() (время собирать урожай)над утилитой класса PlanMetrics (параметры планов).

При этом объект спередается как фактический параметр операции. Затем утилита PlanMetricsвызывает операцию status() (состояние) на некотором неименованномобъекте класса GardeningPlan (план выращивания). В пояснении говорится:"Надо проверить, что этот план действительно выполняется". В свою очередь,объект GardeningPlan вызывает операцию maturationTime() (времясозревания) на выбранном объекте класса GrainCrop (посев зерновых),запрашивающую ожидаемое время созревания посева. Когда эта операцияселектор будет выполнена, управление возвращается объекту классаРис.

5-25. Диаграмма объектов гидропонной системыPlanAnalyst, который затем непосредственно вызывает операциюC.yield(), унаследованную от суперкласса (операция Crop::yield()).Управление снова возвращается объекту класса PlanAnalyst, которыйпродолжает сценарий, выполняя над собой операцию netCost ().На диаграмме показана связь между объектами классов PlanAnalystи GardeningPlan.

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

Мы предупреждали при описаниидиаграмм классов и хотим подчеркнуть опять: дополнительные понятиядолжны использоваться только при необходимости.Роли, ключи и ограничения. Выше мы говорили, что на диаграммеклассов при изображении ассоциации рядом с нею может быть написана еероль, обозначающая намерение или мощность связи одного класса с другим.Для некоторых диаграмм объектов полезно заново написать эту роль приуказании связи между объектами.

Такая метка помогает объяснить, почемуодин объект оперирует над другим.Рис. 5-26 дает пример использования этого дополнительногообозначения. Здесь мы видим, что некоторый объект класса PlanAnalystзаносит информацию об определенном посеве (Crop) в анонимный объектCropEncyclopedia (энциклопедия посевов) и делает это, пока находится вроли Автор.Используя те же обозначения, что и для диаграммы классов, мы можемуказать ключи или ограничения, ассоциированные с объектом или связью.Поток данных.

Как было описано в главе 3, данные могутпередаваться по или против направления посылки сообщения. Иногда явноеуказание направления передачи данных помогает объяснить семантикуконкретного сценария. Мы используем для этого значок, заимствованный изобозначений структурного проектиро-Рис. 5-26. Роливания. На рис. 5-26 дан пример его использования: здесь показано, что послезавершения сообщения insert (вставить) возвращается значение succeeded(успех). Передаваться и возвращаться может либо объект, либо значение.Видимость.

В некоторых запутанных сценариях полезно указатьточно, насколько один объект видит другие. Ассоциации на диаграммахклассов обозначают семантическую зависимость между классами, но неуказывают точно, насколько их экземпляры видят друг друга. С этой цельюмы можем украсить связи на наших диаграммах значками, иллюстрирующимивидимость одного объекта другим. Эта информация важна и дляинструментальных программ, генерирующих код, или наоборот,восстанавливающих по коду логическую модель.Рис. 5-27 уточняет рис.

5-25 и содержит несколько украшений,дающих информацию о видимости. Они похожи на украшения дляфизического вхождения на диаграмме классов. Внутри этих украшенийпомещены буквенные обозначения типа видимости.Например, канал связи от объекта PlanAnalyst к утилите классовPlanMetrics помечен буквой G; это значит, что утилита класса глобальна.Объект с по-разному виден объекту PlanAnalyst и объекту :GardeningPlan: с точки зрения первого объект с класса GrainCrop виденкак параметр некоторой операции (обозначается буквой Р); с точки зрениявторого С виден как атрибут или поле, то есть как часть агрегированногообъекта (обозначен буквой F (field)).Вообще, для указания видимости могут быть использованыследующие обозначения:сервер глобален для клиента•Gсервер является параметром некоторой операции клиента•Рсервер является частью клиента•Fсервер локально определен в области видимости клиента.•LВ соответствии с украшением для физического вхождения, украшениедля видимости представляет собой незакрашенный квадратик с буквой (еслиобъект используется совместно) или закрашенный квадратик с буквой (еслион не используется совместно).

Если украшение видимости не указано, этоозначает, что решение о точном типе видимости осталось не уточненным. Напрактике эти украшения прилагаются только к нескольким ключевым каналамсвязи на диаграмме объектов. Наиболее часто эти украшения указываются дляотношения "часть/целое" (агрегация) между двумя объектами; второенаиболее общее их использование -Рис. 5-27. Значки видимостидля представления объектов, которые по сценарию диаграммы посылаютсякак параметры.Активные объекты и синхронизация. Как отмечалось в главе 3,некоторые объекты могут быть активными, то есть им отводится отдельныйпоток управления.

Другие объекты могут существовать только воднопоточной среде. Третьи, будучи по природе однозадачными,гарантированно переносятся в многопоточную среду.В каждом из этих случаев мы должны ответить на два вопроса: каквыделить активные объекты, управляющие сценарием, и как представитьразличные формы синхронизации объектов.Ранее, говоря о дополнительных элементах спецификаций класса, мызаметили, что есть четыре типа семантики: последовательная, защищенная,синхронизированная и активная. По существу, все объекты класса наследуютсоответствующую семантику класса; все объекты считаютсяпоследовательными, если явно не указано обратное. Мы можем явно показатьмногозадачную семантику объекта на диаграмме объектов, указав в левомнижнем углу значка объекта одно из слов sequential, guarded,synchronous или active.

Например, на рис. 5-28 мы видим, что объекты H, Cи некий экземпляр класса EnvironmentalController - активные.Немаркированные объекты, такие как L, считаются последовательными.Символ синхронизации сообщений, введенный ранее (простаястрелка), представляет обычную последовательную передачу сообщения.Однако, при наличии нескольких потоков управления мы должны указывать идругие формы синхронизации.

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

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

Характеристики

Список файлов книги