Лекция 07-1 (структуризация классов).
advertisement
Технологии разработки программного обеспечения Лекция 9. Структуризация классов программной системы Типы программных систем 1. системы работающие только с людьми – например: информационные системы организаций – используются людьми для ввода, хранения поиска и отображения информации; 2. системы работающие с людьми и внешними техническими устройствами: – например: информационные системы соревнований. 3. системы работающие с внешними техническими устройствами – встроенные системы реального времени – встраиваются в технические устройства для выполнения управления ими. Типы внешних технических устройств • Технических устройства ввода информации – – – – клавиатура (стандартное устройство); датчики; устройство чтения банковских карт … • Технических устройства вывода информации – – – – дисплей (стандартное устройство); принтер; электропривод (исполнительное устройство); … • Технических устройства ввода/вывода информации – сенсорный экран дисплея; –… Типы программных классов • Выделяют следующие типы программных классов : • Связи между классами показывают отношение наследования. Типы классов приложения • Выделяют следующие типы программных классов : • Связи между классами показывают отношение наследования. 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) это программный объект, содержащий подробности прикладной логики. Требуется, когда желательно скрыть прикладную логики отдельно от данных, которые она использует, – • • Например, чтобы прикладной логикой можно было обмениваться независимо от данных. В информационных системах, объекты прикладной логики обычно являются объектами бизнес-логики. А в СРВ, научных и инженерных приложениях, объекты прикладной логики обычно являются алгоритмическими объектами. • Для задания типа конкретного класса на UML диаграммах используются стереотипы. • Такое разделение по типам применяется одинаково и к классам и к объектам. Последовательность выполнения анализ системы 1. Построение концептуальной статической модели системы: – выявляются внешние и интерфейсные классы; – выявляются сущностные классы; 2. Структуризация программных классов статической модели. – выявляются другие программные классы 3. Построение динамической модели системы на основе реализации вариантов использования. Концептуальное статическое моделирование системы • Концептуальная статическая модель создается на раннем этапе анализа. • Концептуальная модель – применяется для моделирования ПрО и – помогает понять проблемы ПрО. • Разработка концептуальной статической модели включает: 1. выделению контекста системы – внешних и интерфейсных классов; 2. выделению сущностных классов. Пример концептуальной статической модели • Концептуальная статическая модели банковской системы. • Банк предоставляет сервисы (услуги) для нескольких Банкоматов (ATM). • Каждый ATM является композитным классом, который включает составные части 1. Моделирование контекста системы Моделирование контекста системы • Важно понять пределы компьютерной системы, – что должно быть включено в саму систему, – что должно остаться вне системы. • Моделирование контекста явно задает, что находится внутри системы, а что находится вне системы. • Моделирование контекста может быть сделано – на уровне всей системы (технического и программного обеспечения) или – на уровне программной системы (только ПО). • В диаграмме классов контекста (ДКК) системы задает явную границу между – системой (технической и программной), рассматриваемой в виде черного ящика, и – внешней средой (которая теперь включает ТО) • Такое задание границ вокруг системы является более детальным, чем то, что обычно показывается в диаграммах вариантов использования. • При разработке ДКК полезно рассматривать – контекст всей технич. и прогр. системы перед тем, как рассматривать – контекст только прогр. системы. • Это особенно, если требуется сделать компромисс между технич. и прогр. обеспечением. • При рассмотрении общего технич. и прогр. контекста, вне системы находятся только – пользователи (т.е. люди - актеры) и – внешние системы. Пример технич. и прогр. системы • На контекстной ДК технич. и прогр. обеспечения банковской системы показываются ее взаимодействие с актерами: – ATM Клиентами и – ATM Операторами • Все другие элементы включаются (как часть) в общую технич. и прогр. систему. Пример контекстной диаграммы классов Банковской Системы • Моделирование контекста системы состоит в следующем: 1. определение внешних сущностей, взаимодействующих с сиcтемой (внешние классы); 2. определение классов, которые будут взаимодействовать с этими внешними сущностями (интерфейсные классы). 1. Моделирование внешних классов Контекст системы • Разрабатываемая программная система должна взаимодействовать с окружающей ее средой. • Такое взаимодействие ПС со средой выполняется посредством внешних объектов (внешних классов), которые составляют контекст системы. • К внешним объектам относятся: – люди (пользователи, клиенты, операторы и т.п.); – датчики (измеряют и передают в систему разные характеристики окружающей среды); – исполнительные устройства (выполняют действия по команде системы – электроприводы, двигатели, и т.п.); – внешние программные системы с которыми должна взаимодействовать разрабатываемая система. Моделирование контекста • С помощью UML создается контекстная диаграмма классов (КДК) для статической модели показывается: – контекст системы техн/прогр системы – показывается в виде агрегированного класса со стереотипом «system», – внешняя среда - изображается в виде внешних классов, для которых данная система должна взаимодействовать. Внешние классы • Все внешние объекты концептуально описываются в виде внешних классов, которые показываются на контекстной ДК, но не входят в ПС. • Выделяются следующие внешние классы: 1. «внешний человек-пользователь» 2. «внешнее устройство», • «внешнее устройство ввода», • «внешнее устройство вывода», • «внешнее устройство ввода/вывода», 3. «внешняя система» или 4. «внешний таймер». Стереотипы для задания типа внешних классов • Внешние классы классифицируются с помощью 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») показывается в контекстной ДК, – если требуется отслеживать время; – и/или если требуется внешний таймер для запуска (инициирования) внешних действий в данной системе. • Классы «внешний таймер» («external timer» classes) наиболее часто требуются в системах реального времени (СРВ). – Пример: в «Автоматизированной Системе Управления ТС» моделируются «Часы» (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. Прокси объекты • Объект-заместитель (прокси объект) взаимодействует и обменивается данными с внешней системой. • Прокси объект является представителем внешней системы и скрывает детали того, «как» выполняется взаимодействие с внешней системой. • Например: прокси класс для робота «Захвати и положи» (Pick & Place Robot). • Каждый прокси объект скрывает детали того, как он взаимодействует и обменивается данными с конкретной внешней системой. • Наиболее вероятно, что прокси объект обменивается данными, с помощью сообщений, с внешней, управляемой компьютером системой (такой, как робот в рассмотренном примере), а не с датчиками и исполнительными устройствами, как это делают граничные объекты устройств ввода/вывода. • Однако, такие задачи рассматриваются уже на этапе проектирования. 3. Объекты интерфейса устройства • Объект интерфейса устройства представляет собой программный интерфейс с аппаратным устройством ввода/вывода. • Для нестандартных устройств требуются объекты интерфейса устройства, относящиеся к уровню приложения. • Чаще они встречаются в системах реального времени, хотя бывают необходимыми и в других системах. • Физический объект в ПрО приложения является объектом реального мира, который имеет физические характеристики. – Например, его может видеть и к нему можно прикоснуться. • Для каждого физического объекта реального мира, который релевантен решаемой проблеме, должен быть соответствующий ему программный объект в системе. • Реальные физические объекты обычно взаимодействуют с системой при помощи датчиков и приводов. • Такие объекты либо передают информацию в систему посредством датчиков, либо получают от нее управляющие воздействия на приводы. • С точки зрения программной системы объекты реального мира — это, по сути дела, устройства ввода/вывода, поставляющие в систему входную информацию и получающие от нее выходную. • Поскольку объекты реального мира соответствуют устройствам ввода/вывода, то осуществляющие интерфейс с ними программные объекты называются объектами интерфейса устройств. • Например, в системе управления лифтами кнопка этажа и индикатор прибытия на этаж это объекты реального мира, обладающие датчиками (устройства ввода), которые передают данные в систему. • Мотор и дверь - объекты, управляемые приводами (устройства вывода), которые получают информацию из системы. • На рис. приведен пример объекта интерфейса устройства ввода на диаграмме коммуникации. • Объект интерфейса устройства ввода — Интерфейс Датчика Температуры - получает информацию о температуре от объекта, представляющего физическое устройство ввода, Датчика Температуры. • Здесь также показана граница между программным и аппаратным обеспечением и стереотипы для аппаратного объекта «внешнее устройство ввода» и программного объекта «интерфейс устройства ввода». • Таким образом, объект интерфейса устройства описывает программный интерфейс с внешним аппаратным устройством. • На рисунке представлена логическая модель задачи, в которой входные данные посылаются аппаратным устройством ввода программному объекту интерфейса устройства. • Во время проектирования принимается решение, должно устройство быть активным (само посылать программному объекту входные данные) или пассивным, (программный объект должен его опрашивать). Объекты интерфейса системы • Объект интерфейса системы осуществляет взаимодействие с внешней системой, которая должна общаться с разрабатываемой системой, и скрывает детали такого взаимодействия. • Пример объекта интерфейса системы — это объект Интерфейс ПодъемноТранспортного Робота в системе автоматизации производства, который осуществляет интерфейс с Подъемно-Транспортным Роботом. • Объект «Интерфейс Подъемно-Транспортного Робота» получает запросы Поднять и Переместить, которые посылает в виде команд внешнему объекту Подъемно-Транспортный Робот. • Робот реагирует на команды, а объект интерфейса системы транслирует реакцию источнику запросов. Моделирование сущностных классов Сущностные классы • Сущностные классы (классы-сущности, entity classes) это концептуальные классы, активно использующие данные. – их основная цель состоит в хранении данных и предоставлении доступа этим данным. • Во многих случаях, классы сущностей являются постоянными (persistent) – эти данные являются долгоживущими и должны храниться файлах или БД. Выявление сущностных классов • Сущностные классы выявляются с помощью ранее рассмотренных методов: – грамматический анализ «существительное глагол»; – CRC анализ; – объектный блиц. Пример концептуальной статической модели : сущностные классы • Концептуальная статическая модель банковской системы: сущностные классы Пример моделирования сущностных классов • Пример моделирования сущностных классов – система онлайн торговли. • В описании проблемы упоминаются: – клиенты (customers), – счета (accounts) и – каталоги (accounts) . • Сущностные классы особенно активно используются в информационных системах. • Однако и многие системы реального времени и встроенные системы также активно используют такие классы, интенсивно работающие с данными. • Сосредоточение на моделировании сущностных классов аналогично моделированию логических схем БД. • Сущностные классы часто на этапе проектирования отображаются на БД. Моделирование атрибутов классов • Важной задачей моделирования классов сущностей является определение атрибутов каждого класса сущностей. • Т.к. класс сущностей активно использует данные, то он должен имеет несколько атрибутов. • Если кажется, что класс сущностей имеет только один атрибут, то тогда возникает вопрос, является ли данный класс действительно классом сущностей. • Есть вероятность, что данная сомнительная сущность должна моделироваться с помощью атрибута какого-то класса Пример атрибутов классов сущностей системы он-лайн торговли Пример сущностного класса и объекта • Для указания сущностного класса, используется стереотип «сущность». • Экземпляры класса Счет - сущностные объекты, которые также снабжены стереотипом «сущность». – Атрибутами класса Счет являются номер Счета и баланс. • Объект Счет - это устойчивый (долго живущий) объект, который участвует в нескольких прецедентах, в том числе инициированных клиентом (снятие денег, получение справки и перевод денег посредством банкомата) или кассиром (открытие и закрытие счета, кредитование и дебетование). Пример сущностного класса и объекта • На рис. показан фрагмент диаграммы коммуникации, объект «Счет» получает сообщения «Открыть», «Закрыть», «Кредитовать», «Дебетовать» и «Прочитать» и отвечает на них, предоставляя информацию о «Балансе» и «Состоянии». • «Счет» также используется в варианте использования ежемесячной подготовки и печати выписок из счета для клиентов. Примером сущностного класса (2) • Примером сущностного класса в приложении, которое занимается мониторингом датчика реального времени, может служить класс «Показания Датчика» (рис. 9.10), где хранится информация об аналоговых датчиках. • Его атрибуты - имя Датчика, значение Датчика, верхний Предел, нижний Предел и состояние Тревоги. • Экземпляром этого класса может быть объект показания Датчика Температуры, который получает сообщения Прочитать и Обновить и отвечает, возвращая Текущие Показания Датчика. • Как показано на рисунке, объект, нуждающийся в получении последних показаний датчика, посылает сообщение Прочитать. • Объект, который считал показания реального датчика и хочет обновить объект показания Датчика Температуры, посылает сообщение Обновить. Второй этап анализа: «Структуризация классов программной системы» Типы программных классов • Выделяют следующие типы программных классов : • Связи между классами показывают отношение наследования. Типы классов приложения • Выделяют следующие типы программных классов : • Связи между классами показывают отношение наследования. Задачи данного этапа • Для объектов и классов ПС определяются типы, к которым они относятся. • Особенное внимание делается дополнительным программным объектам и классам, которые не были определены в ходе концептуального статистического моделирования проблемной ПрО. 1. Управляющим объекты; 2. Объекты прикладной логики. • Для каждой типа объектов имеется некоторый шаблон их поведения объектов, который описывает, как они взаимодействуют со своими соседними объектами. • Полезно понять типичный шаблон поведения объектов, – когда некоторая категория объектов используется в приложении, то очень вероятно, что ее объекты взаимодействует с соседними объектами одинаковых типов аналогичным способом. • Каждый поведенческий шаблон изображается на UML диаграмме коммуникаций. Отнесение объектов к типам • В большинстве случаев, отнесение объекта к определенному типу, является очевидным. • Однако, в некоторых случаях, может оказаться, что объект удовлетворяет более чем одному описанному ранее критерию. • Например: объект может иметь – характеристики сущностного объекта, тем что он инкапсулирует некоторые данные и – характеристики алгоритмического объекта, тем что он выполняет некоторый существенный алгоритм.. • В этом случае данный объект следует отнести к тому типу, которая кажется более подходящей. • Более важно определить все объекты в системе, чем чрезмерно беспокоиться о том, к какому точно типу их отнести в не понятных случаях. 1. Управляющие классы и объекты • Управляющие объекты (control object) это программные объекты, выполняющие координацию работы для наборов объектов. • Управляющие объекты делятся на: 1. координирующие объекты; 2. управляющие объекты, зависящие от состояния; 3. таймерные объекты, связанные с отправкой сообщений в заданные моменты времени. Управляющие объекты (2) • Управляющий объект обеспечивает общую координацию исполнения варианта использования. • Для простых ВИ управляющие объекты не нужны, но для более сложных могут понадобиться. • Управляющий объект похож на дирижера оркестра, который распоряжается поведением других объектов, участвующих в ВИ, говоря каждому из них, что и когда он должен делать. • В зависимости от особенностей ВИ управляющий объект может зависеть или не зависеть от состояния. 1. Объекты-координаторы • Объект-координатор задает весь порядок работы набора взаимосвязанных объектов на основе поступающих входных данных, вне зависимости от состояния. • Он устанавливает, когда и в какой последовательности будут действовать другие объекты, участвующие в прецеденте. • Координатор принимаем решение только на основе поступающих входных данных и не зависят от состояния. • Иными словами, действие, инициированное координатором, определяется исключительно информацией во входном Пример объекта-координатора • Пример объекта-координатора и объектов бизнеслогики. • В банковской системе такими объектами являются – – – – Менеджер Транзакций Снятия, Менеджер Транзакций Перевода, Менеджер Транзакций Получения Справки и Менеджер Транзакций Проверки ПИН-кода. 2. Управляющие объекты, зависящие от состояния • Поведение управляющего объекта, зависящего от состояния, различно в каждом из возможных состояний. • Для определения такого объекта применяется конечный автомат, и графически он изображается на диаграмме состояний. • Существует два вида диаграммы состояний – плоские и – иерархические. • Управляющий объект, зависящий от состояния, получает входные события, которые вызывают переходы между состояниями, и генерирует выходные события, управляющие работой других объектов. • Выходное событие зависит не только от входного, но и от текущего состояния объекта. Пример управляющего объекта, зависящего от состояния • Примером управляющего объекта, зависящего от состояния, служит объект «Управление Банкоматом», определяемый с помощью диаграммы состояний. • Из рисунка видно, что этот объект управляет двумя объектами интерфейса устройства – – Интерфейсом Устройства Печати Чеков и – Интерфейсом Устройства Выдачи Наличных. • В системах реального времени обычно есть один или несколько управляющих объектов, зависящих от состояния. • Может существовать даже несколько объектов одного типа. • Каждый объект исполняет экземпляр одного и того же конечного автомата (изображаемого в виде диаграммы состояний), хотя в каждый момент времени эти объекты, скорее всего, оказываются в разных состояниях. • В банковской системе примерами такого рода являются банкоматы, имеющие собственный зависящий от состояния управляющий объект «Управление Банкоматом», который исполняет свой экземпляр диаграммы состояний. • Другой пример - система управления лифтами, моделируемой с помощью управляющего объекта «Управление Лифтом» посредством диаграммы состояний. • Очевидно, что у любого лифта есть свой объект «Управление Лифтом». 3. Объекты-таймеры • Объект-таймер - это управляющий объект, активизируемый внешним таймером, например тактовым генератором или часами операционной системы. • Объект-таймер либо сам осуществляет некоторое действие, либо активизирует другой объект, который выполнит нужное действие. • Объект «Таймер Пути» активизируется событием, которое генерирует внешний таймер «Тактовый Генератор». • Объект-таймер посылает сообщение «Вычислить объекту Путь», который вычисляет общее пройденное автомобилем расстояние. 2. Классы и объекты прикладной логики • Обычно выделяют 3 типа объектов прикладной 1. Объекты бизнес-логики 2. Алгоритмические объекты 3. Сервисные объекты. • Как и управляющие объекты, объекты прикладной логики наиболее вероятно будут рассматриваться, когда будет разрабатываться в динамическая модель, а не начальная концептуальная модель. 1. Объекты бизнес-логики • Объекты бизнес-логики определяют логику обработки приложением запросов клиентов. • Их назначение заключается в инкапсуляции бизнес-правил, которые могут изменяться независимо друг от друга. • Обычно во время выполнения объекты бизнес-логики обращаются к сущностным объектам. • Объекты бизнес-логики нужны только в некоторых ситуациях. • Иногда бизнес-логику разумно инкапсулировать в отдельный объект, а иногда она настолько проста, что ее можно реализовать в виде операции сущностного объекта. • Общая рекомендация такова: – если для выполнения бизнес-правила приходится обращаться к двум или более сущностным объектам, вводите отдельный объект бизнес-логики; – если же для выполнения правила достаточно одного сущностного объекта, предоставьте это операции самого объекта. Пример объекта бизнес-логики • На диаграмме показан пример объекта бизнес-логики – «Менеджер Транзакций Снятия денег». • Он обслуживает запросы клиентов на снятие денег. • Например: – первое бизнес-правило может состоять в том, что после снятия на счету клиента должно остаться не менее 100 рублей. – Второе правило гласит, что по дебетовой карточке клиент не имеет нрава снимать более 30000 рублей в день. • Менеджер Транзакций Снятия обращается к объекту Счет, чтобы удостовериться в выполнении условий первого правила. • Для проверки второго правила он запрашивает объект Дебетовая Карточка, который хранит накопительный итог сумм, снятых клиентом банкомата в течение дня. Пример объекта бизнес-логики • На диаграмме показан пример объекта бизнес-логики – «Менеджер Транзакций Снятия денег». • Он обслуживает запросы клиентов на снятие денег. • Например: – первое бизнес-правило может состоять в том, что после снятия на счету клиента должно остаться не менее 100 рублей. – Второе правило гласит, что по дебетовой карточке клиент не имеет нрава снимать более 30000 рублей в день. • Менеджер Транзакций Снятия обращается к объекту Счет, чтобы удостовериться в выполнении условий первого правила. • Для проверки второго правила он запрашивает объект Дебетовая Карточка, который хранит накопительный итог сумм, снятых клиентом банкомата в течение дня. • Если хотя бы одно правило не выполняется, запрос на снятие денег отклоняется. • Для выполнения бизнес-правил объект бизнес-логики обычно должен взаимодействовать с сущностными объектами. • В этом отношении он напоминает объект-координатор. • Однако, если в обязанности координатора входит управление работой других объектов, объект бизнес-логики отвечает, прежде всего, за выполнение бизнес-правил. 2. Алгоритмические объекты • Объект-алгоритм инкапсулирует алгоритм, применяемый в данной предметной области. • Такие объекты чаще всего встречаются – в приложениях реального времени, – а также научных и инженерных задачах в тех случаях, когда в предметной области имеется нетривиальный алгоритм, который может изменяться независимо от других ее аспектов. • Простые алгоритмы обычно реализуются как операции сущностного объекта, работающие с хранящимися в нем данными. • Во многих научных и инженерных приложениях алгоритмы уточняются итеративно, поскольку их совершенствование, например с точки зрения производительности и точности вычислений, не зависит от данных. • В системе круиз-контроля объект-алгоритм Крейсер вычисляет, как надо изменить тягу путем сравнения текущей скорости автомобиля с требуемой крейсерской скоростью. • Алгоритм достаточно сложен, поскольку требуется плавно разгонять или притормаживать автомобиль, чтобы пассажиры не испытывали неудобств. • Объект-алгоритм часто инкапсулирует данные, необходимые для выполнения алгоритма. • Это могут быть начальная информация, промежуточные результаты или пороговые данные, например максимальные и минимальные значения. • Объект-алгоритм обычно взаимодействует с другими объектами. В этом отношении он напоминает объект-координатор. • Но в отличие от координатора, который должен управлять другими объектами, назначение объекта-алгоритма состоит, прежде всего, в инкапсуляции и выполнении алгоритма. 3. Сервисные объекты • Сервисный объект это объект, который предоставляет услуги (сервис) для других объектов. • Обычно они используются в сервис-ориентированных архитектурах и приложениях. • Клиентский объект может сделать запрос на услугу от сервисного объекта, на который сервисный объект будет отвечать. • Сервисный объект сам никогда не инициирует запрос, однако, в ответ на запрос в услуге он может искать помощи у других сервисных объектов. • Сервисные объекты играют важную роль в сервисориентированных архитектурах (SOA), хотя они также используются и в других архитектурах, таких, как клиент/серверная архитектуры и основанных на компонентах архитектурах ПО. • Сервисный объект может инкапсулировать данные, которые должны для обработки запроса клиента сервиса или для доступа к другому сущностному объекту (или объектам), которые содержат эти данные. • Примером сервисного класса является «Сервис Каталога» (Catalog Service): • На рис. показан пример выполнения экземпляра класса «Catalog Service». • Объект класса «Catalog Service» предоставляет поддержку для просмотра различных элементов из каталога поставщика и для их выбора. • Координатор «Customer Coordinator» помогает объекту класса «Customer Interaction» найти каталог поставщика, путем предоставления объекта «Catalog Service» и выполнения выборки из данного каталога.
