Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекции - Часть 9.doc
Скачиваний:
33
Добавлен:
02.05.2014
Размер:
5.57 Mб
Скачать

Сервер Банковских Транзакций, Менеджер

Транзакций Проверки ПИН-кода,

Менеджер Транзакций Снятия, Менеджер

Транзакций Справки, Менеджер

Транзакций Перевода, Чековый Счет,

Сберегательный Счет, Дебетовая Карточка,

Карточный Счет, Протокол Транзакций;

временные характеристики:

активизация: асинхронная – по мере поступления сообщений от клиен­тов. Интервал между последовательными поступлениями в худшем слу­чае 100 мс. Среднее время между поступлениями больше 1 с;

время выполнения Сi: 10 мс на одно сообщение;

приоритет.

Высокий – должна успевать отвечать на входные сообщения;

обнаруживаемые ошибки.

Неопознанное сообщение;

логика упорядочения событий.

Определяется на этапе детального проектирования программы.

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

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

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

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

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

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

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

классы интерфейса устройства, взаимодействующие с устройствами вво­да/вывода;

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

классы интерфейса системы, общающиеся с внешней системой или под­системой;

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

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

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

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

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

Соседние файлы в предмете Системы реального времени