Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Проектирование_МПС_лек09

.docx
Скачиваний:
12
Добавлен:
15.02.2015
Размер:
129.45 Кб
Скачать

8

9 Разбиение на классы и объекты

Лекция № 2

9.1 Сущностные объекты

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

Примером сущностного класса из банковского приложения может служить класс «Счет» (рис. 9.1).

Рисунок 9.1 – Пример сущностного класса и объекта банковского приложения

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

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

Примером сущностного класса в приложении, которое занимается мониторингом датчика реального времени, может служить класс «Показания датчика» (рис. 9.2).

Рисунок 9.2 – Пример сущностного класса и объекта приложения реального времени

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

9.2 Управляющие объекты

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

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

Пример объекта-координатора – «Банковский Координатор», который получает клиентскую транзакцию от банкомата. В зависимости от типа транзакции «Банковский Координатор» посылает ее некоторому объекту на исполнение. В банковской системе такими объектами являются «Менеджер Транзакций Снятия», «Менеджер Транзакций Перевода», «Менеджер Транзакций Получения Справки» и «Менеджер транзакций Проверки ПИН-кода» (рис. 9.3)

Рисунок 9.3 – Пример объекта-координатора

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

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

Рисунок 9.4 – Пример управляющего объекта, зависящего от состояния

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

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

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

Рисунок 9.5 – Пример объекта-таймера

9.3 Объекты прикладной логики

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

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

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

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

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

Рисунок 9.6 – Пример объекта-алгоритма

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

9.4 Подсистемы

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

Допустимо также показать отношения между пакетами. На диаграмме пакетов зависимости изображаются пунктирными линиями.

Рисунок 9.7 – Основные подсистемы в виде пакетов

На рис. 9.8 показана декомпозиция банковской системы на подсистемы, которые изображены в виде агрегатных классов. Между «Подсистемой Банковского Сервера» и «Подсистемой Банкомата» существует ассоциация один-ко-многим. Все внешние классы взаимодействуют только с «Подсистемой Банкомата» и связаны с ней ассоциацией один-к-одному.

Рисунок 9.8 – Банковская система: основные подсистемы и их связи