Лекции - Часть 8 - файл n1.doc
Лекции - Часть 8скачать (21919.6 kb.)
Доступные файлы (1):
n1.doc
– поддерживают глобальные транзакции, которые относятся к нескольким распределенным базам данных, в частности гарантируют резервное копирование и восстановление глобальных транзакций;
– реализуют интерфейс с менеджерами ресурсов, например с ОС и СУБД;
– предоставляют средства для администрирования системы.
Современные
ТР-мониторы, такие как
Tuxedo или
Enema, поддерживают трехуровневую архитектуру клиент-сервер:
– функциональность клиента. Представление информации и взаимодействие с пользователем. Например, клиент может находиться на персональном компьютере;
– функциональность сервера приложений, поддерживающего бизнес-логику. Клиент общается с сервером приложений посредством сообщений;
– управление данными. В частности, реляционная база данных под управлением СУБД
Oracle может быть распределена между несколькими узлами.
Изоляция клиента от сервера приложений позволяет раздельно проектировать и разрабатывать пользовательский интерфейс и бизнес-логику.
8. Разбиение на задачи На этапе проектирования подсистем приложение разбивается на отдельные подсистемы. При этом разрабатываются параллельные задачи, о чем пойдет речь далее, и скрывающие информацию классы, из которых создаются пассивные объекты.
Важной целью, стоящей перед разбиением на задачи и классы, является разделение обязанностей. Задача применяет сокрытие информации для инкапсуляции аспектов параллелизма, в том числе деталей синхронизации, управления, упорядочения и коммуникации. Классы скрывают информацию, чтобы инкапсулировать структурные (статические) аспекты, такие как информация об устройствах или абстракции данных. Тип задачи – это активный класс, а сама задача - активный объект. У задачи есть собственный поток управления. Пассивный объект – это экземпляр пассивного класса. При обсуждении проектной модели мы будем использовать термин «объект» для обозначения пассивного объекта, а термин «задача» – для обозначения активного объекта.
На этапе разбиения на задачи разрабатывается архитектура задач, то есть перечень задач в системе, их интерфейсы и способы общения. Для выявления задач применяются критерии разбиения на задачи, они помогают отобразить объектно-ориентированную аналитическую модель системы на параллельную многозадачную архитектуру. Такие критерии представляют собой набор эвристик или рекомендаций, в которых аккумулирован практический опыт специалистов по проектированию параллельных систем и систем реального времени. 8.1. Вопросы разбиения на параллельные задачи Задача – это активный объект, который называют также процессом или потоком. Под задачей мы будем понимать активный объект с единственным потоком управления. В одних системах задача реализуется в виде однопоточного процесса, в других – в виде потока (облегченного процесса внутри тяжеловесного). Проектировщик должен подходить к определению многозадачной структуры очень осторожно. Слишком большое число задач может чрезмерно усложнить систему из-за необходимости заниматься межзадачными коммуникациями и синхронизацией, а также привести к неоправданным накладным расходам на контекстные переключения. Следовательно, проектировщик системы обязан включать задачи с целью упрощения проекта, не допуская появления слишком большого их числа. Между двумя противоречивыми целями надо найти разумный компромисс – именно для этого и предназначены критерии разбиения на задачи, помогающие, кроме того, в анализе альтернативных архитектур.
Структуру параллелизма в системе проще всего понять, описывая ее динамические аспекты. В аналитической модели система представлена в виде набора совместно работающих объектов, обменивающихся сообщениями. В процессе разбиения на задачи природа параллелизма формализуется путем определения параллельных задач и интерфейсов коммуникации и синхронизации между ними.
Объекты, вошедшие в аналитическую модель, рассматриваются с целью выяснить, какие из них могут выполняться параллельно, а какие – только последовательно. Объекты, способные работать параллельно, вычленяются в отдельные задачи. Объекты, которые должны выполняться строго последовательно, объединяются в задачу, которая может охватывать один или несколько объектов. Возможно также, что одна задача будет вызывать одну операцию некоторого объекта, а другая – другую операцию того же объекта.
8.2. Категории критериев разбиения на задачи Критерии разбиения на задачи можно отнести к нескольким категориям по признаку участия в процессе структурирования:
–
критерии выделения задач ввода/вывода. Касаются отображения объектов интерфейса устройств на задачи ввода/вывода и вопроса о моменте активизации таких задач; –
критерии выделения внутренних задач. Связаны с тем, как внутренние объекты отображаются на внутренние задачи и как эти задачи активизируются; –
критерии назначения приоритетов задачам. Позволяют определить относительную важность каждой задачи; –
критерии группировки задач. Позволяют решить, какие объекты следует группировать в параллельные задачи и как именно; –
критерии инверсии задач. Применяются для решения вопроса о том, какие задачи стоит объединить для уменьшения накладных расходов. Это можно делать при исходном разбиении или при пересмотре первоначального проекта. Задачи активизируются периодически или апериодически (по требованию). При определении задачи может использоваться сразу несколько критериев.
Критерии разбиения применяются поэтапно; сначала критерии выделения задач ввода/вывода, критерии выделения внутренних задач и назначения приоритетов. В результате мы получаем взаимно-однозначное соответствие между объектами из аналитической модели и задачами из проектной модели. Затем с целью уменьшения числа задач используются критерии группировки. Опытный проектировщик может выполнять эти шаги одновременно. После того как задачи выявлены, определяются их интерфейсы.
Для изображения различных видов задач задействуются стереотипы. Стереотипами будут также обозначаться разные виды устройств, с которыми общаются задачи. Если в процессе разбиения на задачи некоторый объект определяется как активный, то для него уточняются характеристики соответствующей задачи. Например, активный объект «интерфейс устройства ввода/вывода» считается задачей и характеризуется следующим образом: «асинхронный интерфейс устройства ввода/вывода», «синхронный интерфейс устройства ввода/вывода», «периодический интерфейс устройства ввода/ вывода», «пассивный интерфейс устройства ввода/вывода» или «монитор ресурсов». Точно так же «внешнее устройство ввода» в зависимости от характеристик классифицируется как «асинхронное устройство ввода» или «пассивное устройство ввода».