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

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

Типы внешних технических устройств Технических устройства ввода информации – клавиатура (стандартное устройство); – датчики; – устройство чтения банковских карт – … Технических устройства вывода информации – дисплей (стандартное устройство); – принтер; – электропривод (исполнительное устройство); – … Технических устройства ввода/вывода информации – сенсорный экран дисплея; – …

Общая структура классов проекта Классы внешних объектов, взаимодействующих с программой: – люди; – технические устройства – Они не входят в состав ПС; Классы программы (программные классы): – интерфейсные (граничные) классы – это классы ПС, которые взаимодействуют с внешними классами. – сущностные классы; – управляющие; – …

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

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

Типы объектов и классов Объекты и классы разделяются в соответствии с теми ролями, которые они играют в приложении, на следующие типы: 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) это программный объект, содержащий подробности прикладной логики. Требуется, когда желательно скрыть прикладную логики отдельно от данных, которые она использует, – Например, чтобы прикладной логикой можно было обмениваться независимо от данных. В информационных системах, объекты прикладной логики обычно являются объектами бизнес-логики. А в СРВ, научных и инженерных приложениях, объекты прикладной логики обычно являются алгоритмическими объектами.

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

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

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

Этап анализ программной системы 1.Построение концептуальной статической модели системы. 2.Структуризация классов статической модели. 3.Построение динамической модели системы на основе реализации вариантов использования.

Концептуальное статическое моделирование системы

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

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

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

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

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

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

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

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

Моделирование контекста системы включает: 1.Моделирование внешних классов. 2.Моделирование интерфейсных классов.

Моделирование контекста системы состоит в следующем: 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»).

Возможны и более сложные объекты интерфейса пользователя. Например, объект «Интерфейс Оператора» способен включать несколько более простых. В таком случае оператор увидит в одном окне динамически обновляемое состояние рабочей станции, в другом - состояние тревожных датчиков, а в третьем будет вводить команды для системы. Каждое окно состоит из нескольких элементов управления: меню, кнопок и более простых окон. Заметим, что в аналитическую модель включается только составной объект, дизайн внутренних объектов GUI откладывается до этапа проектирования.

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

Пример шаблона поведения для прокси-объекта показан на рисунке. Прокси-объект для робота «Захвати и положи» который взаимодействует с внешним роботом «Захвати и положи»(External Pick & Place Robot). Прокси-объект для робота «Pick & Place» посылает команды внешнему роботу для захвата деталей и размещения деталей. Реальный робот отвечает на такие команды.

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

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

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

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

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

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

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

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

На рис. представлен объект интерфейса устройства вывода - Интерфейс Красной Лампочки, который передает информацию внешнему объекту реального мира - Приводу Красной Лампочки. Программный объект Интерфейс Красной Лампочки получает запросы Включить и Выключить, которые он передает в виде команды устройству Привод Красной Лампочки. На рисунке показана также граница между программным и аппаратным обеспечением.

Аппаратное устройство может реализовывать одновременно функции ввода и вывода. Ему соответствует программный объект интерфейса устройства ввода/ вывода. Именно так обстоит дело в случае объекта Интерфейс «Устройства Чтения Карточек» в банкомате; он получает данные от внешнего «Устройства Считывания Карточек», а также команды Вернуть и «Конфисковать» от системы, которые передает устройству.

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

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

Например, в «Автоматизированной Системе Управления ТC» двигатель ТС и манипулятор являются релевантными физическими объектами, т.к. они взаимодействуют с ПС. С другой стороны, шасси ТС и колеса не являются релевантными физическими объектами, т.к. они не взаимодействуют с ПС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Второй этап анализа: «Структуризация классов программной системы»

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

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

Задачи данного этапа Для объектов и классов ПС определяются типы, к которым они относятся. Особенное внимание делается дополнительным программным объектам и классам, которые не были определены в ходе концептуального статистического моделирования проблемной ПрО. 1.Управляющим объекты; 2.Объекты прикладной логики.

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

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

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

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

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

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

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

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

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

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

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

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

Объекты прикладной логики два вида объектов прикладной логики: – объекты бизнес-логики и – объекты-алгоритмы.

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

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

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

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

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

For example, 1.the first business rule is that the customer must have a minimum balance of $50 after the withdrawal takes place; 2.the second business rule is that the customer is not allowed to withdraw more than $250 per day with a debit card. The Withdrawal Transaction Manager object accesses an Account object to determine if the first business rule will be satisfied. It accesses the Debit Card object, which maintains a running total of the amount withdrawn by an ATM customer on this day, to determine if the second business rule will be satisfied. If either business rule is not satisfied, the withdrawal request is rejected. A business logic object usually has to interact with entity objects in order to execute its business rules. In this way, it resembles a coordinator object. However, unlike a coordinator object, whose main responsibility is to supervise other objects, the prime responsibility of a business logic object is to encapsulate and execute the business rules.

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

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

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

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

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

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