Технологии разработки программного обеспечения Лекция 9. Структуризация классов программной системы

Последовательность выполнения анализа системы 1.Построение концептуальной статической модели системы: – выявляются внешние и интерфейсные классы; – выявляются сущностные классы; 2.Структуризация программных классов статической модели. – выявляются другие программные классы 3.Построение динамической модели системы на основе реализации вариантов использования.

Концептуальная статическая модель создается на раннем этапе анализа. Концептуальная модель – применяется для моделирования ПрО и – помогает понять проблемы ПрО. Разработка концептуальной статической модели включает: 1.выделению контекста системы – внешних и интерфейсных классов; 2.выделению сущностных классов.

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

Типы объектов и классов Объекты и классы разделяются в соответствии с теми ролями, которые они играют в приложении, на следующие типы: 1. сущностные классы (entity class); 2. интерфейсные (граничные классы, boundary class); 3. управляющие классы (control class); 4. классы прикладной логики (application logic class). Большинство приложений будет включать объекты всех 4 типов. Однако, разные виды приложений будут иметь наибольшее количество классов какого-то одного типа.

Типы программных классов Обычно выделяют следующие типы программных классов : Связи между классами показывают отношение наследования.

Типы классов приложения Обычно выделяют следующие типы программных классов : Связи между классами показывают отношение наследования.

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

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

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

2. Интерфейсный (граничный) объект Граничный объект (boundary object) это программный объект, который взаимодействует и обменивается информацией с внешней средой (контекстом). Граничные объекты далее делятся на следующие подтипы: 1.объект взаимодействия с пользователем (user interaction object) - программный объект, взаимодействующий и предоставляющий интерфейс для пользователя – человека; 2.объект – заместитель (Proxy object) - программный объект, который взаимодействует и обменивается информацией с внешней системой или подсистемой; 3.объект взаимодействующий с устройством ввода/вывода (device I/O boundary object).

3. Управляющий объект Управляющий объект (control object) это программный объект, выполняющий координацию работы набора объектов. Управляющие объекты делятся на следующие подтипы: 1.координирующие объекты; 2.управляющие объекты, зависящие от состояния; 3.таймерные объекты, формирующие сообщения по заданному временному.

4. Объект прикладной логики Объект прикладной логики (application logic object) это программный объект, содержащий подробности прикладной логики. Требуется, когда желательно скрыть прикладную логики отдельно от данных, которые она использует, – Например, чтобы прикладной логикой можно было обмениваться независимо от данных. В информационных системах, объекты прикладной логики обычно являются объектами бизнес-логики. А в СРВ, научных и инженерных приложениях, объекты прикладной логики обычно являются алгоритмическими объектами.

5. Сервисные объекты Сервисные объекты это еще один тип программных объектов. Они предоставляют сервисы клиентским объектам, обычно в сервис- ориентированных архитектурах (Service- Oriented Architectures, SOA) и приложениях.

UML стереотипы Для задания типа конкретного класса на UML диаграммах используются стереотипы. Каждый поведенческий шаблон изображается на UML диаграммах в виде > Такое разделение по типам применяется одинаково и к классам и к объектам.

1. Моделирование контекста системы

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

Моделирование контекста системы состоит в следующем: 1.определение внешних сущностей, взаимодействующих с сиcтемой (внешние классы); 2.определение классов, которые будут взаимодействовать с этими внешними сущностями (интерфейсные классы).

В диаграмме классов контекста (ДКК) системы задает явную границу между – системой (технической и программной), рассматриваемой в виде черного ящика, и – внешней средой (которая теперь включает ТО) Такое задание границ вокруг системы является более детальным, чем то, что обычно показывается в диаграммах вариантов использования.

Пример технич. и прогр. системы На контекстной ДК технич. и прогр. обеспечения банковской системы показываются ее взаимодействие с актерами: – ATM Клиентами и – ATM Операторами Все другие элементы включаются (как часть) в общую технич. и прогр. систему.

Пример контекстной диаграммы классов Банковской Системы

Стереотипы для задания типа внешних классов Внешние классы также описываются с помощью UML стереотипов. На схеме показаны типы внешних классов. Каждый прямоугольник представляет разные типы внешних классов, а связи между ними отношения наследования.

Пример стереотипов для внешних классов Стереотипы для классификации внешних классов системы: – «external user» («внешний пользователь»), – «external system» («внешняя система»), – «external timer» («внешний таймер»).

Классы внешних устройств далее классифицируются следующим образом: 1.внешние классы устройств ввода (например: датчики); 2.внешние классы устройств вывода (например, исполнительные механизмы (приводы, actuator)); 3.внешние классы устройств ввода/вывода (ATM card reader).

Пример диаграммы классов контекста Контекстная диаграмма классов для Банковской Системы.

Пример диаграммы классов контекста (2) Диаграмма классов контекста Банковской Системы со стереотипами

Моделирование человека- пользователя системой Человек-пользователь часто взаимодействует с ПС с помощью стандартных устройств ввода/вывода, таких, как клавиатура/дисплей и «мышь». – Характеристики таких стандартных устройств не являются важными, т.к. они управляются ОС. Более важным является интерфейс с пользователем в терминах – информации, которая выводится для пользователя и – информации, которая вводится пользователем. Поэтому внешний пользователь, взаимодействующий с системой при помощи стандартных устройств, моделируется как «внешний пользователь», а не как устройство.

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

Для встроенных систем реального времени желательно выявлять низкоуровневые внешние классы, которые соответствуют физическим устройств ввода/вывода, для которых ПС должна выполнять взаимодействие. Такие внешние классы показываются с помощью стереотипа «внешнее устройство ввода/вывода» («external I/O device»).

Примерами таких внешних устройств I/O в «Автоматизированной Системе Управления Транспортными средствами» являются: – внешнее устройство ввода - «Датчика прибытия» (Arrival Sensor); – внешнее устройство вывода - «Двигатель» (Motor).

Класс «внешняя система» Класс «внешняя система» («external system») требуется, в том случае, если разрабатываемая система взаимодействует с другими системами (посылает или получает от них данные). – Например, в «Автоматизированной Системе Управления ТC») система взаимодействует с двумя внешними системами: 1.Управляющая система 2.Показывающая система

Класс «внешний таймер» Класс «внешний таймер» («external timer») показывается в контекстной ДК, – если требуется отслеживать время; – и/или если требуется внешний таймер для запуска (инициирования) внешних действий в данной системе. Классы «внешний таймер» наиболее часто требуются в системах реального времени (СРВ). – Пример: в «Автоматизированной Системе Управления ТС» моделируются «Часы» (Clock). – Они требуются, т.к. ПС требуются события от внешнего таймера, чтобы инициировать различные периодически повторяющиеся действия.

Связи внешних классов с системой Ассоциации между внешними классами и агрегированным классом ПС и показывается на контекстной диаграммы классов. Также показывается имя и кратность (multiplicity) таких ассоциаций. Стандартными именами таких ассоциаций в контекстной ДК ПС являются 1. «Вводить_в» (Inputs to); 2. «Выводить_в» (Outputs to); 3. «Общаться_с» (Communicates with); 4. «Взаимодействовать_с» (Interacts with); 5. «Отправлять_сигналы» (Signals).

Примеры использования ассоциаций «внешнее устройство ввода» Вводит-в «система» «система» Выводит-на «внешнее устройство вывода» «внешний пользователь» Взаимодействует_с «система» «внешняя система» Соединена-с «системой» «внешний таймер» Пробуждает «систему»

Пример диаграммы классов контекста Диаграмма классов контекста Банковской ПС.

Пример автоматизированной системе управления транспортом «Автоматизированной Системе Управления Транспортными средствами» с стереотипами внешних классов.

Выявление интерфейсных (граничных) классов

Интерфейсные классы Внешние классы это классы, описывающие сущности, которые находятся вне системы и взаимодействуют с ней. Интерфейсные (граничные) классы это классы, находящиеся внутри системы, которые взаимодействуют и обмениваются данными с внешними классами. Для определения интерфейсных классов программной системе, необходимо рассмотреть внешние классы, с которыми они связаны.

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

Типы интерфейсных классов 1.Классы интерфейсов пользователя. 2.Классы прокси-объектов. 3.Классы интерфейсов устройств.

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

Пример показа внешних и интерфейсных классов Внешние и интерфейсные классы в банковской системе

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

Пример класса и объекта взаимодействия с пользователем Пример представления простого класса, выполняющего взаимодействие с пользователем, который называется «Operator Interaction»:

Объекты интерфейса пользователя Примером простого объекта интерфейса пользователя является «Интерфейс Оператора», который – принимает команды оператора, – запрашивает показания датчика от сущностного объекта «Хранилище Показаний Датчика» и – отображает полученные данные на дисплее.

Объект интерфейса пользователя может быть составным и включать несколько более простых объектов. Это значит, что актеры взаимодействуют с системой при помощи нескольких объектов интерфейса пользователя, последовательно или параллельно. Для таких объектов предусмотрен стереотип «интерфейс пользователя» («user interaction»).

2. Прокси объекты Объект-заместитель (прокси объект) взаимодействует и обменивается данными с внешней системой. Прокси объект является представителем внешней системы и скрывает детали того, «как» выполняется взаимодействие с внешней системой. Например: прокси класс для робота «Захвати и положи».

Каждый прокси объект скрывает детали того, как он взаимодействует и обменивается данными с конкретной внешней системой. Наиболее вероятно, что прокси объект обменивается данными, с помощью сообщений, с внешней, управляемой компьютером системой (такой, как робот в рассмотренном примере), а не с датчиками и исполнительными устройствами, как это делают граничные объекты устройств ввода/вывода. Однако, такие задачи рассматриваются уже на этапе проектирования.

3. Объекты интерфейса устройства Объект интерфейса устройства представляет собой программный интерфейс с аппаратным устройством ввода/вывода. Для нестандартных устройств требуются объекты интерфейса устройства, относящиеся к уровню приложения. Чаще они встречаются в системах реального времени, хотя бывают необходимыми и в других системах.

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

Реальные физические объекты обычно взаимодействуют с системой при помощи датчиков и приводов. Такие объекты либо передают информацию в систему посредством датчиков, либо получают от нее управляющие воздействия на приводы. С точки зрения программной системы объекты реального мира это, по сути дела, устройства ввода/вывода, поставляющие в систему входную информацию и получающие от нее выходную. Поскольку объекты реального мира соответствуют устройствам ввода/вывода, то осуществляющие интерфейс с ними программные объекты называются объектами интерфейса устройств.

Пример объекта интерфейса устройства ввода на диаграмме коммуникации. Объект интерфейса устройства ввода «Интерфейс Датчика Температуры» получает информацию о температуре от объекта, представляющего физическое устройство ввода, - Датчика Температуры.

Моделирование классов сущностей

Сущностные классы Сущностные классы (классы-сущности, entity classes) это концептуальные классы, активно использующие данные. – их основная цель состоит в хранении данных и предоставлении доступа этим данным. Во многих случаях, классы сущностей являются постоянными (persistent) – эти данные являются долгоживущими и должны храниться файлах или БД.

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

Пример атрибутов классов сущностей системы он-лайн торговли

Выявление сущностных классов Сущностные классы выявляются с помощью ранее рассмотренных методов: – грамматический анализ «существительное глагол»; – CRC анализ; – объектный блиц.

Пример концептуальной статической модели : сущностные классы Концептуальная статическая модель банковской системы: сущностные классы

Пример моделирования сущностных классов Пример моделирования сущностных классов – система он- лайн торговли. В описании проблемы упоминаются: – клиенты (customers), – счета (accounts) и – каталоги (accounts).

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

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

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

Примером сущностного класса (2) Примером сущностного класса в приложении, которое занимается мониторингом датчика реального времени, может служить класс «Показания Датчика» (рис. 9.10), где хранится информация об аналоговых датчиках. Его атрибуты - имя Датчика, значение Датчика, верхний Предел, нижний Предел и состояние Тревоги. Экземпляром этого класса может быть объект показания Датчика Температуры, который получает сообщения Прочитать и Обновить и отвечает, возвращая Текущие Показания Датчика. Как показано на рисунке, объект, нуждающийся в получении последних показаний датчика, посылает сообщение Прочитать. Объект, который считал показания реального датчика и хочет обновить объект показания Датчика Температуры, посылает сообщение Обновить.

3. Управляющие классы и объекты Управляющие объекты (control object) это программные объекты, выполняющие координацию работы для наборов объектов. Управляющие объекты делятся на: 1.координирующие объекты; 2.управляющие объекты, зависящие от состояния; 3.таймерные объекты, связанные с отправкой сообщений в заданные моменты времени.

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

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

Пример объекта-координатора Пример объекта-координатора и объектов бизнес- логики. В банковской системе такими объектами являются – Менеджер Транзакций Снятия, – Менеджер Транзакций Перевода, – Менеджер Транзакций Получения Справки и – Менеджер Транзакций Проверки ПИН-кода.

2. Управляющие объекты, зависящие от состояния Поведение управляющего объекта, зависящего от состояния, различно в каждом из возможных состояний. Для определения такого объекта применяется конечный автомат, и графически он изображается на диаграмме состояний. Существует два вида диаграммы состояний – плоские и – иерархические. Управляющий объект, зависящий от состояния, получает входные события, которые вызывают переходы между состояниями, и генерирует выходные события, управляющие работой других объектов. Выходное событие зависит не только от входного, но и от текущего состояния объекта.

Пример управляющего объекта, зависящего от состояния Примером управляющего объекта, зависящего от состояния, служит объект «Управление Банкоматом», определяемый с помощью диаграммы состояний. Из рисунка видно, что этот объект управляет двумя объектами интерфейса устройства – – Интерфейсом Устройства Печати Чеков и – Интерфейсом Устройства Выдачи Наличных.

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

В банковской системе примерами такого рода являются банкоматы, имеющие собственный зависящий от состояния управляющий объект «Управление Банкоматом», который исполняет свой экземпляр диаграммы состояний. Другой пример - система управления лифтами, моделируемой с помощью управляющего объекта «Управление Лифтом» посредством диаграммы состояний. Очевидно, что у любого лифта есть свой объект «Управление Лифтом».

3. Объекты-таймеры Объект-таймер - это управляющий объект, активизируемый внешним таймером, например тактовым генератором или часами операционной системы. Объект-таймер либо сам осуществляет некоторое действие, либо активизирует другой объект, который выполнит нужное действие. Объект «Таймер Пути» активизируется событием, которое генерирует внешний таймер «Тактовый Генератор». Объект-таймер посылает сообщение «Вычислить объекту Путь», который вычисляет общее пройденное автомобилем расстояние.

4. Классы и объекты прикладной логики Обычно выделяют 3 типа объектов прикладной 1.Объекты бизнес-логики 2.Алгоритмические объекты 3.Сервисные объекты. Как и управляющие объекты, объекты прикладной логики наиболее вероятно будут рассматриваться, когда будет разрабатываться в динамическая модель, а не начальная концептуальная модель.

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

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

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

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

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

В системе круиз-контроля объект-алгоритм Крейсер вычисляет, как надо изменить тягу путем сравнения текущей скорости автомобиля с требуемой крейсерской скоростью. Алгоритм достаточно сложен, поскольку требуется плавно разгонять или притормаживать автомобиль, чтобы пассажиры не испытывали неудобств.

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

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

Сервисный объект может инкапсулировать данные, которые должны для обработки запроса клиента сервиса или для доступа к другому сущностному объекту (или объектам), которые содержат эти данные. Примером сервисного класса является «Сервис Каталога» (Catalog Service):

На рис. показан пример выполнения экземпляра класса «Catalog Service». Объект класса «Catalog Service» предоставляет поддержку для просмотра различных элементов из каталога поставщика и для их выбора. Координатор «Customer Coordinator» помогает объекту класса «Customer Interaction» найти каталог поставщика, путем предоставления объекта «Catalog Service» и выполнения выборки из данного каталога.