Itogi_Shpory

64. Спецификация поведения задачи

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

СПЗ прилагается к описанию архитектуры задач. В процессе разбиения на задачи в СПЗ заносится информация о входных и выходных данных задачи. Часть СПЗ составляется позже, на этапе детального проектирования программы. Речь идет о логике упорядочения событий – описании того, каким образом задача отвечает на входные события.

Пример спецификации поведения для задачи «Банковский Сервер». СПЗ для задачи

Банковский Сервер, выглядит следующим образом. Задача: Банковский Сервер.

• интерфейс задачи:

– входные данные:

Сильно связанный обмен сообщениями с ответом. Сообщения:

– ПроверитьПИН-код.

Входные параметры: идКарточки, ПИН-код. Ответ: результатПроверкиПИН-кода;

– снять.

Входные параметры: идКарточ-ки, номерСчета, сумма.

Ответ: результатСнятия;

– справка.

Входные параметры: идКарточки, номерСчета. Ответ: результатСправки;

– перевести.

Входные параметры: идКарточки, исходныйСчет, Целевой Счет,сумма.

Ответ: результатПеревода;

65. Проектирование классов

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

66. Проектирование классов, скрывающих информацию

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

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

всебе информацию и существуют в течение длительного времени.

–интерфейсные классы, использующие интерфейс с внешней средой, можно разделить на следующие группы:

классы интерфейса устройства, взаимодействующие с устройствами ввода/вывода; классы интерфейса пользователя, осуществляющие человеко-машинный интерфейс; классы интерфейса системы, общающиеся с внешней системой или подсистемой;

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

–классы прикладной логики, представляющие особенности логики и алгоритмов приложения, подразделяются на классы бизнес-логики и классы алгоритмов;

–внутренние программные классы, скрывающие те решения проектировщиков, которые могут впоследствии измениться.

67. Проектирование операций классов

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

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

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

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

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

68. Классы абстрагирования данных

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

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

Атрибуты объекта Наличные банкомата: это количество пяти-, десяти- и двадцатидолларовых купюр в устройстве выдачи наличных. Так, в объекте должны быть внутренние переменные, содержащие соответствующие счетчики купюр. Таким образом, мы проектируем класс Наличные Банкомата с четырьмя атрибутами:

имеющаясяСумма, пятидолларовыеКупюры, десятидолларовые Купюры,

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

69. Классы интерфейса устройства

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

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

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

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

количествоТоплива.

70. Классы, зависящие от состояния

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

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

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

Прекратить. Теперь объект Управление Калибровкой отправляет сообщение Прекратить объекту Калибровочная Константа.

71. Классы, скрывающие алгоритмы

Эти классы скрывают алгоритмы, которые применяются в предметной области; они типичны в системах реального времени, а также в научных и инженерных приложениях. Обычно, такой класс скрывает не только алгоритм, но и локальные данные, необходимые для его работы.

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

расчета средней скорости движения. Обе эти операции вызывают операцию вывести

объекта Интерфейс Маршрутного Дисплея, передавая среднюю Скорость в качестве параметра.

72. Классы интерфейса пользователя

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

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

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

вывестиОкноСнятияДенѐг, вывестиОкноПеревода Денег и вывестиОкноСправки – а

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

Класс Интерфейс Клиента – это составной класс, включающий несколько низкоуровневых классов, как показано на рис.9.76. В него входят классы для каждого окна, необходимого при организации интерфейса с клиентом: окно Главного Меню,

Окно ПИН-кода, ОкноСнятия Денег, Окно Перевода Денег, Окно Справки и Окно Приглашения.

73. Классы бизнес-логики

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

В качестве примера можно привести класс Менеджер Принятия Заказов, где находятся правила обработки запроса на принятие заказа.

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

Проектная модель (диаграмма кооперации и диаграмма классов) стоится на основе анализа диаграммы кооперации.

74. Классы-обертки базы данных

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

Атрибуты сущностного класса становятся отношениями в базе, а операции доступа к атрибутам встраиваются в класс-обертку.

Пример класса-обертки базы данных:

а – аналитическая модель; б – проектная модель

Отношение в реляционной базе данных:

ДебетоваяКарточка (идентификаторКарточки, ПИН<код, датаНачала, датаОкончания, состояние, лимит, итог, НСС клиента)

(подчеркнут главный ключ, курсивом выделен внешний ключ)

75. Внутренние программные классы

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

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

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